Permitiendo la administración de la nube basada en la aplicación

Tres pasos para automatizar el despliegue y la administración de la aplicación y la carga de trabajo

La administración de aplicaciones y cargas de trabajo complejas en la nube requiere la automatización puntual de la reconfiguración de infraestructura. La administración basada en la aplicación — en la cual sus esfuerzos de administración se concentran en el control de todos los recursos necesarios como sistema unificado y los parámetros para todos los servicios como definición única del sistema — puede proporcionar una forma alternativa para mantener el nivel de performance de su nube al máximo que es igual de efectiva. Este artículo presenta una definición de administración de estilo basado en la aplicación, los tres pasos claves para lograrla, y cómo automatizar el despliegue de una aplicación J2EE de dos niveles en la nube de IBM®. Usted puede practicar la creación de acciones, la conexión de acciones a eventos, y la administración de eventos

Joydeep Biswas, Senior Software Developer, Kaavo

Joydeep Biswas trabaja como desarrollador senior de software en Kaavo y se encarga de los productos IMOD. Posee más de cinco años de experiencia en el desarrollo de aplicaciones empresariales Java. Joydeep posee un BEng y un MEng en Ciencias Informáticas e Ingeniería de la Universidad de Jadavpur, una de las mejores diez universidades de la India. En la Universidad de Jadavpur, Joydeep recibió una medalla de oro por graduarse como el mejor de su clase.



03-02-2010

Los despliegues se tornan más complejos gracias a las necesidades en aumento de recursos informáticos. La administración de estas aplicaciones y cargas de trabajo complejas en la nube sin ningún nivel de automatización oportuna en la configuración de la infraestructura puede tornarse casi imposible para el ocupado departamento de IT. Además los proveedores de la nube deben tener la habilidad para administrar las excepciones de producción, los niveles de servicio y los recursos de la aplicación y de la carga de trabajo, y organizar actividades sin intervención del hombre.

Los proveedores del servicio de infraestructura ofrecen ahorros en los costos a través de despliegue en la nube. Para lograr esto, las herramientas suplementarias del ciclo de vida son necesarias para administrar correctamente las aplicaciones con el fin de lograr eficiencias. Y los usuarios deben poder configurar firewalls, desplegar y configurar automáticamente software en la infraestructura en la nube para ejecutar y administrar sus aplicaciones y cargas de trabajo. La administración basada en la aplicación— un enfoque verticalista para la computación en nube que significa la administración de los servicios, el software, la infrastructura, el middleware, la red, y el almacenaje necesarios para la ejecución de aplicaciones y cargas de trabajo en la nube desde la perspectiva del dueño de la aplicación — permite al usuario administrar todos los recursos necesarios como un sistema unificado para una aplicación determinada.

En este artículo se describe la administración basada en la aplicación y usted verá cómo automatizar el despliegue y la administración de cualquier aplicación o carga de trabajo en público, en privado, y en nubes híbridas a través de la administración basada en la aplicación. Como ejemplo, se presenta un caso de uso que despliega una aplicación J2EE de dos niveles con un balanceador de carga y servidores J2EE, junto con la automatización para el autoescalamiento, la autorecuperación, etc., para administrar los niveles del servicio de tiempos de ejecución. Nuestro ejemplo es desplegado en el IBM Smart Business Development and Test Cloud y el proceso puede aplicarse a cualquier entorno nube; el ejemplo utiliza IMOD (consulte sidebar). IMOD es un framework basado en tecnología pendiente de patente diseñada por Kaavo que automatiza el despliegue y la administración del tiempo de ejecución de cualquier aplicación o carga de trabajo compleja multiservidor y multinivel.

La centricidad en la aplicación es un enfoque universal

En un entorno nube basado en la aplicación, usted administra sistemas para aplicaciones determinadas en lugar de administrar servidores y routers. Todos los recursos necesarios para una aplicación determinada son administrados como un sistema unificado; toda la información para el despliegue y la administración de los niveles de servicios de tiempo de ejecución para los recursos requeridos por una aplicación determinada son capturados en una única definición de sistema. A esto nos referimos como enfoque verticalista.

En contraste, en un enfoque basado en la infraestructura o ascendente, los recursos (servidores, almacenamiento, y recursos de red) son administrados individualmente.

La administración basada en la aplicación le da a los dueños de la aplicación mayor flexibilidad, control, visibilidad, automatización, y seguridad para los recursos de infraestructura utilizados por sus aplicaciones.

Aunque se utiliza una aplicación específica de Java™ a través del software IMOD para ilustrar un enfoque de administración de nube basada en la aplicación, los conceptos y técnicas pueden aplicarse a otras aplicaciones y otros sistemas. Por ejemplo:

  • El archivo de definición del sistema (utilizado para definir la aplicación multinivel) es un archivo XML.
  • Los ejemplos de código suministrados en este artículo se encuentran en XML y en script de shell.
  • Los asistentes gráficos para autogenerar el XML sin que los usuarios deban ingresarlo.
  • Los conceptos de los componentes definidos en el archivo de definición del sistema para este artículo — acción, evento, nivel, etc. — son todas las partes genéricas de una aplicación web multinivel, en este caso una aplicación J2EE.
  • El mismo software IMOD está diseñado para interactuar con cualquier plataforma nube y actualmente está integrada por cinco nubes diferentes.

Tres claves para establecer la administración basada en la aplicación en IMOD

Hay tres pasos claves para crear un sistema de administración basado en la aplicación en la nube:

  1. Definir la aplicación. Esto incluye:
    • La definición de la estructura del sistema.
    • La configuración de los grupos de servidores.
    • La definición de las acciones.
    • La definición de las conexiones para los eventos estándar.
    • La definición de los eventos personalizados.
  2. Configurar el autopiloto.
  3. Iniciar/desplegar el sistema.

Más adelante en este artículo, verá cómo usar este enfoque para automatizar el despliegue de una aplicación J2EE de dos niveles en la nube de IBM.


Sobre el lenguaje de scripting

Los ejemplos de códigos en este artículo son scripts comunes de línea de comando; básicamente comandos que un sistema admin utilizará al realizar manualmente los pasos descriptos en los ejemplos. Los scripts de propiedades o los lenguajes de programación no son utilizados.

Los scripts son una secuencia de comandos para los servidores destino. Estos pueden ser scripts shell, scripts Perl, scripts Python, etc. Cuando los scripts necesitan información disponible sólo en el tiempo de ejecución, utilice Apache Velocity templates para generar dinámicamente aquellos scripts.

El cuerpo de la install-jdk action es un script de shell que contiene invocaciones de comandos Linux estándar como wget, tar, etc., como se observa en el siguiente código; cualquier otro lenguaje de script puede utilizarse.

script de shell de muestra
/usr/bin/wget -O /opt/jdk1.6.tar.gz http://SOURCE.com/jdk1.6.0_16.tar.gz
cd /opt/
 tar -xzvf jdk1.6.tar.gz
ln  -s /opt/jdk1.6.0_16/ /usr/local/java

Los archivos de configuración son administrados de modo similar. La acción configure-apache-balancer tiene un cuerpo como el que se observa en este código:

Muestra de archivo de configuración
<Proxy balancer://mycluster>
                    #foreach ($node in $AppNodes)
                    BalancerMember http://$node.publicIP:8080
                   #end
        </Proxy>
           ProxyPass /app balancer://mycluster
        <Location /balancer-manager>
                     SetHandler balancer-manager
                     Order Deny,Allow
                     Allow from all
         </Location>

Cuando se proporciona esta plantilla, se genera un archivo de configuración para apache mod_proxy. Los archivos de definición de sistema basados en XML no son utilizados para describir la aplicación, pero si se usan en general para la representación interna.

Existen varios asistentes GUI para la autogeneración de archivos de definición de sistemas. El siguiente fragmento XML es generado por el asistente.

Fragmento XML generado por el asistente
          <serverType role="ndbd" min="1" max="6"> 
           <ibmServer> 
            <name>AppNode</name>  
            <ibmAccount>xxxx</ibmAccount>  
            <keypair>yyyy</keypair>  
            <imageIdentifier>20001150</imageIdentifier>  
            <instanceType>BRZ32.1/2048/175</instanceType>  
            <location>41</location>  
            ..........//Event and other information              
            <startupCount>2</startupCount>  
          </ibmServer> 
         </serverType>

Ejemplo: definición de la aplicación

El primer paso para un enfoque de administración basado en la aplicación para administrar aplicaciones es definir la aplicación, por lo tanto definamos los componentes para IMOD y lo que cada uno hace.

Kaavo's IMOD

Kaavo's IMOD utiliza tecnología de patente pendiente para la administración basada en la aplicación de recursos virtuales en las nubes. IMOD proporciona una interfaz web de fácil uso para el despliegue, la ejecución, y la administración de aplicaciones multiservidor complejas de nivel n en nubes públicas, privadas, e híbridas. Si desea más información, consulte los productos y la tecnología de Kaavo.

En IMOD, una aplicación multinivel completa (o un sistema) es definido usando un archivo XML denominado System Definition file (consulte el N-Tier Guide System Definition wiki en Resources si desea más información). Después de que el sistema sea definido, con un solo clic se despliega toda la aplicación.

El archivo de definición del sistema tiene dos componentes: tiempo de despliegue y tiempo de ejecución:

  • El componente despliegue contiene toda la información sobre el abastecimiento de recursos y despliegues, y configura el middleware y los componentes de la aplicación para colocar la aplicación en línea.
  • El componente tiempo de ejecución tiene los flujos de trabajo que deben ejecutarse en respuesta a los eventos definidos para asegurarse de que los niveles del servicio de la aplicación sean alcanzados durante el tiempo de ejecución automáticamente y sin intervención humana.

Una vez que el sistema sea desplegado, tiene la funcionalidad "autopiloto" que le permitirá aerodinamizar y automatizar el soporte de producción para su aplicación.

Algunos de los otros bloques de creación de IMOD incluyen

  • Servidor
  • Tipo de servidor, grupo de servidor
  • Nivel
  • Nivel N
  • Acción: acciones ejecutables y no ejecutables
  • Eventos: eventos comunes y personalizados

Veamos cada uno en detalle.

Servidor

Un servidor directamente representa un servidor o instancia virtual en la nube. Éste es especificado por varios parámetros — cuentas de servicios nube para utilizar para el suministro de la instancia ibmAccount), imágenes para crear la instancia desde (imageIdentifier), tipos de instancias (instanceType), etc. El Listado 1 muestra cómo especificar una instancia en la nube de IBM usando XML.

Listado 1. Especificación de una instancia en la nube de IBM usando XML
<ibmServer> 
  <name>AppNode</name>  
  <ibmAccount>xxxx</ibmAccount>  
  <keypair>yyyy</keypair>  
  <imageIdentifier>20001150</imageIdentifier>  
  <instanceType>BRZ32.1/2048/175</instanceType>  
  <location>41</location>  

  ..........//Event and other information    
  <startupCount>2</startupCount>  
</ibmServer>

Tipo de servidor, grupo de servidor

En IMOD, los servidores están organizados en grupos. Un grupo puede tener cualquier tamaño dentro de un rango específico; el tamaño del grupo depende de la escala del despliegue.

Todo grupo comienza con un tamaño inicial y puede variar en el tiempo de ejecución dependiendo de la carga del tiempo de ejecución y de la configuración autopiloto. Todos los miembros del grupo son creados iguales, pero la configuración de los diversos servidores dentro de un mismo grupo puede variar levemente.

El ejemplo de los grupos de servidores contiene grupos de nodos ndbd en un cluster mysql, grupos de nodos de administrador en un cluster mysql, grupos de nodos jboss en un cluster jboss, etc.

El Listado 2 muestra un fragmento XML que describe un tipo de servidor. El role únicamente identifica un tipo de servidor. Los atributos min y max representan un tamaño máximo y mínimo del grupo. La etiqueta startupCount representa el tamaño inicial del grupo.

Listado 2. Fragmento XML que describe el tipo de servidor
<serverType role="ndbd" min="1" max="6"> 
          <ibmServer> 
            <name>AppNode</name>  
            <ibmAccount>xxxx</ibmAccount>  
            <keypair>yyyy</keypair>  
            <imageIdentifier>20001150</imageIdentifier>  
            <instanceType>BRZ32.1/2048/175</instanceType>  
            <location>41</location>  
            ..........//Event and other information              
            <startupCount>2</startupCount>  
          </ibmServer> 
</serverType>

Arquitectura de nivel N

Multinivel o nivel n es una arquitectura de servidor de cliente en la cual la presentación, el procesamiento de la aplicación, y la administración de los datos son procesos lógicamente separados. El principal beneficio de la arquitectura de nivel N es que permite a los desarrolladores crear aplicaciones que sean más flexibles y reutilizables dado que sólo hay que modificar el nivel destino al realizar los cambios o actualizaciones. Un buen ejemplo de una aplicación de nivel n es una que utiliza middleware para administrar solicitudes de servicio entre los usuarios y una base de datos. La arquitectura de nivel tres es la más utilizada.

Nivel

El nivel representa directamente un nivel en una aplicación multinivel. Un nivel está compuesto de una cantidad de grupos de servidores. Por ejemplo, el nivel de una base de datos basada en clusters mysql estaría comprendida por dos grupos de servidores, un grupo ndbd y un grupo administrador. Cuando una aplicación multinivel es desplegada, sus niveles son desplegados en secuencia siguiendo el orden de inicio especificado para los niveles. El Listado 3 muestra un fragmento XML para un nivel de la base de datos con dos grupos de servidores.

<tier displayindex="3">
      <name>db_tier</name>  
      .....//Event and other information 
      <serverTypes>
        
	   <serverType role="manager" min="1" max="1">
          <ibmServer>
            ....
          </ibmServer>
        </serverType>  

        <serverType role="ndbd" min="2" max="2">
          <ibmServer>
            ...
          </ibmServer>
        </serverType>

      </serverTypes>
</tier>

Nivel N

Este representa la aplicación multinivel y está comprendido por varios niveles. En el Listado 4 se observa el fragmento XML para un nivel n.

Listado 4. Fragmento XML para un nivel n
<ntier>
    .../Event and other information
    <tier displayindex="1">
     ...
    </tier>
    
    <tier displayindex="2">
     ...
    </tier>

    <tier displayindex="3">
     ...
    </tier>

</ntier>

Acción

Las acciones son algo así como procedimientos reutilizables. Son utilizadas para generar scripts ejecutables y archivos de configuración a partir de plantillas velocity y copiarlas en los servidores destino, y opcionalmente ejecutarlas (en caso de scripts ejecutables). Existen dos tipos de acciones:

  • Ejecutable
  • No ejecutable

Acciones ejecutables
Las acciones ejecutables generan un script ejecutable y copian el script en una ubicación determinada en el conjunto de servidores determinado. El Listado 5 es un ejemplo de una acción ejecutable.

Listado 5. Una acción ejecutable
<action name="start-apache" execute="true" 
 target="[tier=web_tier][serverrole=default]">
       <scriptName>apache.sh</scriptName>
       <scriptPath>/root</scriptPath>
       <scriptTemplate type="inline">
       <![CDATA[
               /etc/init.d/httpd start
               ]]>
       </scriptTemplate>

</action>
  • El atributo execute especifica si la acción es o no ejecutable. En este ejemplo, execute="true" especifica que la acción es ejecutable.
  • El atributo target representa el conjunto de servidores en los cuales el script será ejecutado. La expresión [tier=web_tier][serverrole=default] devuelve el conjunto de servidores en el denominado tier(web_tier) y con el denominado server type(default).
  • El elemento scriptPath especifica el directorio donde será copiado el script generado; scriptName especifica el nombre del archivo con el cual se guardará el script.
  • El elemento scriptTemplate contiene el cuerpo de la acción. El cuerpo de la acción es una plantilla Velocity (Velocity es un motor de plantilla basado en Java que permite a los diseñadores web consultar métodos definidos en código Java). Pero en este ejemplo trivial, el texto es estático.

Las acciones pueden invocarse dentro de los administradores de eventos usando la siguiente sintaxis:

<command type="action" name="action-name" />

Es fácil ver que cuando se ejecuta esta acción, o cualquier otra acción ejecutable para esta cuestión, los siguientes tres pasos son ejecutados para cada servidor destino:

  1. La plantilla Velocity es representada utilizando el motor de plantilla Velocity. En este ejemplo, la plantilla tiene texto estático, de modo que el contenido generado es el mismo que el de la plantilla (por ejemplo, /etc/init.d/httpd start).
  2. Un archivo con el contenido generado es creado en la ruta /root/apache.sh en el servidor destino.
  3. El script /root/apache.sh es ejecutado en el servidor destino.

La Figura 1 demuestra cómo la ejecución de acciones es registrada principalmente para fines de auditoría y para la eliminación de fallar.

Figura 1. Ejemplo de Registro de acciones
Ejemplo de Registro de acciones

El Listado 6 muestra otro ejemplo con una plantilla Velocity no común.

Listado 6. Otro ejemplo de plantilla Velocity no común
      <scriptName>GrantPhpDbAccess.sh</scriptName>  
      <scriptPath>/root</scriptPath>  
      <scriptTemplate type="inline">
         
        <![CDATA[
#!/bin/sh
#foreach ($clientNode in $SqlClientNodes)
mysql -uroot -p${mysqladminpassword} -e "GRANT ALL PRIVILEGES ON ${appdb}.*
   TO '${appdbuser}'@'${clientNode.publicIP}' IDENTIFIED BY '${appdbpassword}'"
#end	  
        ]]> 
      </scriptTemplate>  
      <parameters> 
        <parameter name="mysqladminpassword" type="literal" value="kaavo"/>  
        <parameter name="appdb" type="literal" value="php_collab"/>  
        <parameter name="appdbuser" type="literal" value="phpcollab"/>  
        <parameter name="appdbpassword" type="literal" value="admin"/>  
        <parameter name="SqlClientNodes" type="serverref" 
         value="[tier=app_tier][serverrole=default]"/> 
      </parameters>      
 </action>

El cuerpo de la acción ahora tiene contenido dinámico. Esta acción acepta cinco parámetros: mysqladminpassword, appdb, etc. Estos tienen valores por omisión determinados usando el atributo value.

Los primeros cuatro parámetros (type="literal") son inicializados a strings determinados usando el atributo value. El último (SqlClientNodes) es inicializado a una serie de objetos de servidor devueltos por la expresión [tier=app_tier][serverrole=default]. Cuando se ejecuta esta acción en el paso 1 anterior ("la plantilla Velocity es representada usando el motor de plantilla Velocity"), se resuelven referencias a estos parámetros mientras se representa la plantilla.

Cada objeto de servidor tiene varias propiedades (por ejemplo, publicIP) a las que se puede acceder desde la plantilla. El bucle foreach itera sobre la colección $SqlClientNodes con el $clientNode como la variable del bucle. En cada iteración del bucle, ${clientNode.publicIP} busca la IP pública de los objetos del servidor. Esta acción genera el siguiente script:

Listado 7. Cada iteración del bucle busca la IP pública de los objetos del servidor
#!/bin/sh
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIP1' IDENTIFIED BY 'admin'
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIP2' IDENTIFIED BY 'admin'
...
...
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIPn' IDENTIFIED BY 'admin'

Donde publicIP1, publicIP2, ..., publicIPn representa las IPs públicas de todos los servidores en la colección SqlClientNodes (o en otras palabras, las IPs públicas de todos los servidores en el nivel, app_tier, y server type=default.)

Los parámetros recién presentados son parámetros definidos por el usuario. Además de estos, hay tres parámetros implícitos a los que pueden hacer referencia en la plantilla:

  • CurrentTarget (el nodo en el cual está siendo creado el script).
  • AllTargets (conjunto de todos los nodos que son destino de la acción).
  • OtherTargets (conjunto de todos los nodos excepto CurrentTarget).

(La N-Tier Guide -guía de nivel N- en Resources puede proporcionarle una lista abarcativa de las propiedades de los objetos del servidor y los parámetros implícitos.)

Pueden agregarse acciones al sistema y también editarlas en cualquier fase del ciclo de vida del sistema usando un asistente (Figura 2).

Figura 2. Incorporación de una acción usando un asistente
Incorporación de una acción usando un asistente

Acciones no ejecutables
Las acciones no ejecutables son similares a las acciones ejecutables; la única diferencia es que estas acciones generan archivos no ejecutables en los pasos anteriores 1 y 2. Y el paso 3 no existe para este tipo de acciones porque para ellas, el atributo execute se establece como false.

Eventos

Un Nivel N, un nivel, un grupo de servidores, o cada uno de los servidores de un grupo se controlan enviando eventos a los mismos. Un evento tiene un objetivo determinado. Los eventos pueden dispararse de diferentes formas:

  • Manualmente: los usuarios pueden disparar eventos usando la interfaz de usuario.
  • Mediante el organizador de eventos.
  • Realizando una llamada de servicio web (lo cual permite a los usuarios interactuar programáticamente con IMOD a través de SOAP usando un estilo document/literal wrapped).
  • Estableciendo un trigger (disparador) en el sistema de monitoreo (consulte la N-Tier Guide o guía de nivel N).

Hay dos tipos de eventos: eventos comunes y personalizados.

Eventos comunes
Los eventos comunes son eventos predefinidos. Estos eventos son definidos siempre que un sistema se define en IMOD.

Hay dos tipos de eventos comunes: Start y Stop. El nivel N, nivel, y servidor (grupo) pueden ser un objetivo de estos eventos, de modo que por cada uno de ellos habrá un evento start y un evento stop. Por ejemplo, start ntier, start tier1, start tier2, start server1, start server2, stop tier1, etc.

Todo nivel tiene un administrador que es un bloque de código ejecutado en respuesta a la ocurrencia de un evento. Para los eventos comunes, los administradores de eventos son predefinidos, y el comportamiento por omisión de estos administradores de eventos puede personalizarse implementando enlaces predefinidos para ellos. Los eventos start tienen enlaces post-startup; los eventos stop tienen enlaces pre-shutdown. El Listado 8 muestra la estructura de estos administradores de eventos.

Listado 8. La estructura de los administradores de eventos en pseudocódigo
Proc Start-server-handler
  Begin
       Execute start-server-default-logic
       Execute post-startup hook
  END

Proc Stop-server-handler
  Begin
       Execute pre-shutdown hook
       Execute stop-server-default-logic       
  END

La lógica por omisión para el servidor (a la que nos referimos como start-server-default-logic en el Listado 8) consiste en suministrar un servidor en la nube back-end. La lógica por omisión para el servidor stop consiste en eliminar el servidor. Los enlaces post-startup y pre-shutdown están vacíos por omisión.

Eventos personalizados
Además de los eventos comunes que están disponibles por omisión, los usuarios pueden definir sus propios eventos. El Listado 9 es un ejemplo de un evento personalizado.

Listado 9. Un usuario definido, un evento personalizado
<event name="system-scaleup" description="App system scaleup" type="custom"> 
      <handler timeout="6000"> 
        <pre-process> 
          	<startServers> 
            	       <serverType role="[tier=app_tier][serverrole=default]" count="1" 
                          addToEvent="true"/> 
          	</startServers> 
        </pre-process>  
        <process> 
         	 <command type="action" name="start-app" 
              target="[tier=app_tier][serverrole=default][scaleupserver]"/>  
          <command type="action" name="configure-apache-balancer"/>  
          <command type="action" name="reset-apache"/>        
        </process> 
     </handler> 
 </event>

Un evento es identificado por un nombre y el administrador del evento y es definido junto con el evento. Por lo tanto si el evento en el Listado 9 es definido en un sistema siempre que ocurre un evento con el nombre system-scaleup, el administrador especificado es ejecutado.

El administrador del evento inicia un nuevo servidor y lo configura ejecutando una secuencia de comandos en él. Este tipo de administrador de eventos puede utilizarse para escalar verticalmente un sistema existente mediante más instancias.

De modo similar, los eventos pueden definirse recuperando un servidor muerto (Listado 10).

Listado 10. Los eventos definidos para la recuperación de servidores muertos
<event name="server-recovery" description="App server recovery" type="custom"> 
      <handler timeout="6000"> 
        <pre-process> 
          <recoverServers> 
            		<server server-to-recover="[context=event][param=instanceid]"/> 
          </recoverServers> 
        </pre-process>  
        <process> 
         	 <command type="action" name="start-app" 
              target="[tier=app_tier][serverrole=default][recoveringserver]"/>  
          	<command type="action" name="configure-apache-balancer"/>  
          	<command type="action" name="reset-apache"/> 
        </process> 
      </handler> 
 </event>

Tales elementos, como startServers, recoverServers, y stopServers están disponibles sólo en el administrador de eventos de eventos personalizados.

De nuevo, consulte la N-Tier Guide (Guía del nivel N ) en Resources si desea una descripción más detallada sobre los eventos personalizados.


Ejemplo: diseño del sistema

Un solo servidor que ejecute la aplicación habría alcanzado para esta demostración, pero para ilustrar ciertas características se lo ha diseñado como múltiples servidores de carga balanceada que ejecutan la aplicación (a la que nos referiremos con el nombre de app). El sistema ha sido diseñado como un sistema de dos niveles con un nivel de app que se ejecuta en la aplicación J2EE y un nivel de balanceador de carga. La Figura 3 ilustra la arquitectura del despliegue de la forma más sencilla posible.

Figura 3. La arquitectura del despliegue de dos niveles
La arquitectura del despliegue de dos niveles

Las razones para utilizar dos niveles separados es que el motor de nivel N de IMOD nos permite definir el orden de despliegue entre los niveles. El archivo de configuración del balanceador de carga se refiere a las direcciones IP de los servidores de la aplicación, por lo tanto el balanceador de carga no puede configurarse antes de que los servidores de la aplicación estén funcionando y hayan sido asignadas sus direcciones IP.

Esta arquitectura debe mapearse en un sistema de nivel N de IMOD. Los elementos claves necesarios en pocas palabras son:

  1. Dos niveles.
  2. Dos grupos de servidores.
  3. Varias acciones (instalación, configuración, inicio, y reinicio).
  4. Enlaces para eventos comunes.
  5. Una cantidad de eventos personalizados (escalamiento vertical y horizontal, y recuperación de un servidor muerto).
  6. Disparar las condiciones y parámetros para los eventos personalizados.

Veamos cada uno en detalle.

1. Dos niveles

Llamemos a los dos niveles app-tier (el nivel de la aplicación) y lb-tier (el nivel del balanceador de carga). App-tier contiene un grupo de servidores (app-group) y lb-tier contiene un grupo de servidores (lb-group).

2. Dos grupo de servidores

Los dos grupos de servidores, app-group y lb-group, presentados en la última sección, se logran con diferentes conjuntos de servidores. app-group se logra con la imagen de la base de IBM SUSE Linux Enterprise Server 11 (x86); lb-group se logra con la imagen de la base de Red Hat Enterprise Linux 5.4 (32-bit).

3. Varias acciones

Las acciones requeridas deben ocuparse de la instalación, la configuración, el inicio y el reinicio de servidores, y la apertura de puertos.

Ejecución de la instalación de Apache en servidores lb-group
Llamemos a esto install-apache. Este es un script estático y ya sirve como la plantilla Velocity requerida. Se realiza como el siguiente código.

Action-type: executable 
Script to be executed:

wget http://3rdparty-tools.s3.amazonaws.com/apache/httpd-2.2.14.tar.gz
 tar -xzvf  httpd-2.2.14.tar.gz
 cd httpd-2.2.14
 export CFLAGS=-O2
 ./configure --prefix=/usr/local/apache2 --enable-mods-shared=all
  --enable-proxy_balancer=shared --enable-proxy_http=shared --enable-rewrite=shared
  --enable-proxy=shared
 make
 make install
 echo "Include conf/extra/httpd-IMOD.conf" >> /usr/local/apache2/conf/httpd.conf

Configuración de balanceador de carga de Apache en servidores lb-group
Llamemos a esto, configure-apache-balancer.

Action-type: non-executable
Config file to be copied:
<Proxy balancer://mycluster>
                    	
        BalancerMember http://publicIP1:8080
        BalancerMember http://publicIP2:8080
        ....
        ....
        BalancerMember http://publicIPn:8080
                   	
</Proxy>
ProxyPass /app balancer://mycluster
<Location /balancer-manager>
        SetHandler balancer-manager
        Order Deny,Allow
        Allow from all
</Location>

En este caso, publicIP1, publicIP2, ...., y publicIPn son IPs públicas de servidores de carga balanceada; en otras palabras, los servidores app-group en el app-tier.

Evidentemente, necesitará una acción dinámica parametrizada aquí para generar líneas BalancerMember que dependan de publicIPs de todos los servidores [tier=app-tier][serverrole=app-group] . Esta información no se conoce hasta que esos servidores estén funcionando.

Aquí se presenta la plantilla Velocity requerida para esta acción:

<Proxy balancer://mycluster>
       #foreach ($node in $appNodes)
       BalancerMember http://$node.publicIP:8080
       #end
</Proxy>
  ProxyPass /app balancer://mycluster
<Location /balancer-manager>
       SetHandler balancer-manager
       Order Deny,Allow
       Allow from all
</Location>

Aquí las líneas BalancerMember son generadas por el bucle foreach que itera en la colección de servidores requeridos ( $appNodes). Esta colección se debe ingresar como parámetro.

Inicio de Apache en servidores lb-group y apertura de puertos
Llamemos a esto start-apache. Este es un script estático.

Action-type: executable
Script to be executed:

cp httpd-IMOD.conf /usr/local/apache2/conf/extra/
/usr/local/apache2/bin/apachectl start
sed -i 's/COMMIT/-A INPUT -p tcp -m tcp --dport 80 
  -j ACCEPT\n-A INPUT -p tcp -m
    tcp --dport 10050 -j ACCEPT\nCOMMIT/g' /etc/sysconfig/iptables
/etc/init.d/iptables restart

La instalación y el inicio de la aplicacion en servidores app-group y la apertura de puertos
Esto se denomina start-app. La información detallada — nombre del archivo de software tar, destino de URL de archivo tar, etc. — variará según la aplicación J2EE que utilice.

Action-type: executable
Script to be executed:

/usr/bin/wget -O /opt/ APP .tar.gz 
http:// SOURCE .com/ APP .tar.gz
cd /opt
tar -xzvf  APP .tar.gz
ln  -s /opt/ APP  /usr/local/ APP 
export JAVA_HOME=/usr/local/java;
/usr/local/ APP /bin/startup.sh
sed -i 's/^.*FW_SERVICES_EXT_TCP=".*".*$/FW_SERVICES_EXT_TCP="8080 10050"/g'
 /etc/sysconfig/SuSEfirewall2
/etc/init.d/SuSEfirewall2_setup reload

Instalación del Java Development Kit
O install-jdk.

Action-type: executable
Script to be executed:

/usr/bin/wget -O /opt/jdk1.6.tar.gz 
 http:// SOURCE .com/jdk1.6.0_16.tar.gz
cd /opt/
tar -xzvf jdk1.6.tar.gz
ln  -s /opt/jdk1.6.0_16/ /usr/local/java

Reinicio de Apache luego de cambiar el archivo de configuración del balanceador de carga
Denominado restart-apache.

Action-type: executable
Script to be executed:
               
/usr/local/apache2/bin/apachectl stop
sleep 5
rm -rf /usr/local/apache2/conf/extra/httpd-IMOD.conf
cp httpd-IMOD.conf /usr/local/apache2/conf/extra/
/usr/local/apache2/bin/apachectl start

4. Enlaces para eventos comunes

Estos enlaces generalmente se ocupan de eventos start.

Enlace post-startup para evento start para servidores lb-group
Para la invocación secuencial de las acciones mencionadas:

{install-apache->configure-apache-balancer->start-apache}

Enlace post-startup para evento start para servidores app-group

{install-jdk}

Enlace post-startup para evento start para app-tier

{start-app}

5. Varios eventos personalizados

Los eventos personalizados que requeriremos serán utilizados para:

  • Escalar verticalmente app-group (app-group-scaleup; Listado 9).
  • Recuperar un servidor muerto en el app-group (app-group-recovery; Listado 10).
  • Escalar horizontalmente app-group (app-group-scaledown).

6. Condiciones de disparadores y parámetros para eventos personalizados

Y usted debe decidir las condiciones de los disparadores y parámetros para cada uno de los eventos personalizados en la sección anterior:

  • La métrica para medir (por ejemplo, CPU Utilization:User).
  • El/los grupo(s) de servidor(es) en los cuales medir esa métrica.
  • La condición para el disparador: >, <, =, != threshold.
  • El tipo de disparador: Aggregate or non-aggregate.
  • El valor umbral (N).
  • El período de tiempo (T).

Ejemplo: Implementación del sistema

Una vez que la fase de diseño esté completa, es hora de llevar el diseño a papel en un sistema de nivel n. Con IMOD, esto se hace usando distintos asistentes gráficos; en este artículo no trataremos la implementación manual y "práctica" de esto.

La fase de diseño descripta en este artículo le ofrece las acciones para start-app, install-apache, configure-apache-balancer, etc. En la fase de implementación de Kaavo IMOD, todo lo que tendría que hacer es ingresar estas acciones en los asistentes gráficos.


En conclusión

Sin importar el esfuerzo que se realice por simplificarlos, los entornos nube siempre comprenderán aplicaciones de administración compleja y una serie de cargas de trabajo que deberá ser balanceada. La habilidad para reconfigurar automáticamente la infraestructura de manera oportuna es clave para una administración de la nube buena y sin dificultades.

Un componente crítico para una rápida autoreconfiguración es la administración basada en la aplicación — traer el control de los recursos y parámetros necesarios para los servicios del tiempo de ejecución en la definición de un único sistema puede ofrecer un modo efectivo de administrar la performance en el sistema de la nube.

En este artículo se presentó la administración basada en la aplicación junto con una explicación de sus beneficios. Se abarcaron los tres pasos para alcanzarla:

  1. Cómo definir la aplicación (lo cual incluye la definición de la infraestructura del sistema, los grupos de servidores para la configuración, y las acciones decisivas, enlaces para los eventos comunes y para los personalizados).
  2. Cómo establecer el autopiloto.
  3. Cómo iniciar y desplegar el sistema.

Usted conoció algo sobre el código XML para automatizar el despliegue de aplicaciones J2EE de dos niveles en la nube de IBM; la creación de la acción de los detalles del código, el enlace de acciones a eventos, y la administración de eventos. Estos ejemplos de código provienen de la experiencia en el mundo real relacionada al desarrollo y despliegue de Kaavo IMOD.

Espero que aplique estas técnicas (o los conceptos que ellas representan) en su próximo proyecto para facilitar el despliegue y la administración de aplicaciones y servicios en la nube.

De nuevo, consulte la N-Tier Guide (Guía del nivel N) en Resources para obtener una descripción más detallada de los eventos personalizados.

Recursos

Aprender

Obtener los productos y tecnologías

  • Usted puede descargar Apache Velocity, el motor de plantilla basada en Java que permite a los diseñadores de páginas webs consultar métodos definidos en código Java.
  • Con el IBM trial software, el cual se puede descargar directamente desde developerWorks, cree su próximo proyecto de desarrollo.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing, tecnologia Java
ArticleID=964023
ArticleTitle=Permitiendo la administración de la nube basada en la aplicación
publish-date=02032010