Los dispositivos virtuales son el concepto clave en el modelo de aplicación.
Un dispositivo virtual es un objeto instanciable que está formado por un límite y un interior. El límite incluye todo lo necesario para configurar el dispositivo, vincularlo a los datos de los volúmenes de almacenamiento externo y conectarlo a otros dispositivos. El interior está formado por una máquina virtual y un volumen de arranque que contiene el SO, los archivos de configuración y el software de aplicación que se ejecuta dentro del dispositivo.
La ilustración anterior muestra de forma más detallada la anatomía de un dispositivo virtual típico. El límite del dispositivo está formado por los elementos siguientes:
El interior del dispositivo está formado por una máquina virtual y un volumen de arranque. El volumen de arranque se configura con una versión apropiada de Linux, y todos los demás paquetes de software y scripts necesarios para que funcione el dispositivo. La máquina virtual se configura para que arranque desde el volumen de arranque y tiene varias tarjetas de interfaz de red virtuales.
La vNIC eth0 siempre se configura como interfaz predeterminada, lo que permite iniciar sesión en el dispositivo, instalar el software y solucionar los problemas que pueda presentar, de la misma forma que lo haría con cualquier servidor remoto.
Además, CA AppLogic® crea una vNIC independiente para cada terminal (entrada o salida) definido en el límite del dispositivo. Aunque es posible dirigir todo el tráfico dentro y fuera del dispositivo a través de una sola vNIC, el hecho de tener una vNIC para cada terminal, hace que a CA AppLogic® le resulte más fácil adaptar y controlar el tráfico de red, imponer protocolos de conexión y mejorar la seguridad.
El límite contiene un conjunto de propiedades específicas del dispositivo o parámetros que se pueden utilizar para configurar el dispositivo. Cuando se inicia el dispositivo, CA AppLogic® automáticamente crea una variable de entorno para cada propiedad y la inicializa con el valor que se haya asignado a dicha propiedad. Además, CA AppLogic® propaga los valores de la propiedad en uno o varios de los archivos de configuración incluidos en el volumen de arranque. Esto facilita el uso de propiedades como mecanismo primario para configurar dispositivos.
El límite puede contener también uno o varios marcadores de volumen. Un marcador es una ranura predefinida para un volumen de almacenamiento La ranura se ocupa al configurar el dispositivo con el nombre del volumen que desea montar. Esto proporciona el equivalente virtual de un disco extraíble. Muchos de los dispositivos utilizan este mecanismo para acceder a contenido como páginas HTML, código personalizado o bases de datos.
CA AppLogic® también asigna a cada dispositivo un presupuesto de recursos de hardware que incluye un conjunto de tres intervalos que definen el uso mínimo y máximo de CPU (unidad de procesamiento central), memoria y ancho de banda para el dispositivo.
Finalmente, CA AppLogic® asocia a cada dispositivo un conjunto de atributos de ejecución que afectan a la forma en que el sistema planifica y ejecuta el dispositivo. Es probable que utilice frecuentemente dos de esos atributos: el valor del orden de inicio y el indicador de migrabilidad. El orden de inicio permite especificar y cambiar el orden en que se inician los dispositivos de la misma aplicación, teniendo en cuenta las dependencias entre ellos. El indicador de migrabilidad es verdadero de forma predeterminada e indica a CA AppLogic® que se puede migrar este dispositivo de un servidor a otro a criterio del planificador. Si este indicador se establece en falso, se podrá guardar el dispositivo en un servidor específico.
CA AppLogic® trata los dispositivos virtuales como objetos componentes de primera clase. Cuando se crea un nuevo tipo de dispositivo, lo que se está creando realmente es una clase de dispositivo, lo que permite a CA AppLogic® saber cómo fabricar tales dispositivos (denominados instancias de la clase) a petición. Las clases de dispositivos no se pueden ejecutar, ya que son plantillas para crear instancias. Una aplicación en ejecución real contiene solamente instancias, configuradas e interconectadas para que funcionen de manera conjunta.
La ilustración anterior muestra cómo CA AppLogic® instancia clases. Todas las clases tienen un descriptor de clase asociado, que define:
La definición completa de una clase está formada por su descriptor de clase y todo el conjunto de volúmenes de clase identificados en el descriptor, incluido su contenido: el SO, el software de aplicación y los scripts que definen de manera conjunta el comportamiento del dispositivo.
Las clases de dispositivo corrientes pueden producir cualquier número de instancias. Los singleton son clases limitadas a una sola instancia al mismo tiempo. Los singleton son útiles cuando es necesario editar una clase o solucionar sus problemas. Debido a que en el sistema solamente se pueden ejecutar instancias, siempre será necesaria una instancia para probar la clase y solucionar sus problemas. Los singleton hacen más sencillo este proceso. Permiten probar la instancia y solucionar sus problemas, y, a continuación, generar una nueva clase automáticamente a partir de la instancia que funciona correctamente.
La definición de clase no es suficiente para crear una instancia en ejecución que pueda utilizarse. Para ello, CA AppLogic® también tiene que conocer los valores de configuración de la instancia: un conjunto de parámetros que definen cómo se va a conectar, configurar y ejecutar la instancia. Los valores de configuración de la instancia están formados por valores específicos para los recursos de hardware, los atributos de ejecución, las conexiones de terminales, las propiedades del dispositivo y los nombres de volúmenes externos.
Para crear una instancia, CA AppLogic® interpreta el descriptor de la clase y crea una máquina virtual con un adaptador de red virtual para cada terminal y un dispositivo en bloque virtual para cada volumen. A continuación, crea una instancia de una interfaz de red virtual para cada uno de los adaptadores y la vincula al adaptador apropiado.
Después, el sistema crea una instancia de volumen virtual para cada volumen especificado en el descriptor mediante la replicación del volumen de la clase apropiado y la vincula al dispositivo en bloque correspondiente.
La instancia que acaba de crearse se configura con los valores de la propiedad, normalmente mediante la modificación de los archivos de configuración identificados en la definición de clase y ubicados en uno o varios de los volúmenes instanciados. Debido a que cada volumen de la instancia es una copia del volumen de la clase correspondiente, estas modificaciones son particulares de la instancia.
A continuación, CA AppLogic® inicia la máquina virtual, lo que da lugar al arranque e inicio de los distintos servicios configurados en el dispositivo. Utiliza los recursos de hardware y los atributos de ejecución para controlar el inicio, la colocación, la planificación y la migración de la instancia que acaba de crearse.
CA AppLogic® separa los datos de configuración y conexión específicos de cada instancia del dispositivo de la información común a todos los dispositivos de una clase determinada, incluidos el código del SO, el código del motor de aplicación y los parámetros de configuración necesarios para que funcionen de manera conjunta.
A diferencia de los atributos de ejecución, que se pueden aplicar a cualquier dispositivo, se pueden definir parámetros de configuración específicos para cada clase de dispositivo. CA AppLogic® proporciona un mecanismo de propiedad para definir y editar un conjunto de tales parámetros de configuración a través de una interfaz de propiedad universal.
Para aprovechar las ventajas del mecanismo de propiedad, se definen las propiedades especificando sus nombres, tipos de datos y valores predeterminados como parte de la definición de la clase. También puede seleccionar uno o varios de los archivos de configuración ubicados en los volúmenes del dispositivo como destinos para los valores de la propiedad.
Desde una instancia del dispositivo, puede acceder a un valor de la propiedad de una o dos formas:
Para cada propiedad del límite del dispositivo, CA AppLogic® define una variable de entorno nombrada después de la propiedad. En el momento del arranque, el valor de la variable se inicializa con el valor asignado a la propiedad. De este modo, los daemon, las utilidades y los scripts que se ejecutan dentro del dispositivo pueden acceder fácilmente a las propiedades.
Nota: Las propiedades definidas en un dispositivo se pueden utilizar para establecer los valores de uno o varios parámetros ubicados en archivos de configuración basados en texto. Para asignar una propiedad del dispositivo a un parámetro de un archivo de configuración, es necesario designar el valor en el archivo con un comentario etiquetado especial que identifique el nombre de la propiedad que está intentando asignar. Una vez establecida la propiedad, CA AppLogic® reemplazará el valor encontrado en el archivo por el valor asignado a la propiedad.
Los terminales de CA AppLogic® son puntos de conexión para interacciones lógicas entre dispositivos. La abstracción de terminales está diseñada para que los paquetes de software existentes dentro de los dispositivos virtuales se puedan comunicar a través de terminales sin necesidad de realizar ninguna modificación.
Los terminales pueden ser entradas o salidas. Las entradas son terminales para aceptar conexiones de red. Las salidas son terminales para originar conexiones de red. Con respecto a los flujos de solicitudes y datos, los dos tipos de terminales son bidireccionales. Un terminal está formado por un nombre de red, un adaptador de red virtual y una interfaz de red virtual.
Cuando una salida de un dispositivo se conecta a una entrada de otro dispositivo, CA AppLogic® crea un cable virtual entre sus respectivas interfaces de red virtuales y asigna direcciones IP virtuales a los dos extremos de la conexión.
Nota: Las direcciones IP virtuales sólo son para uso del software que se ejecuta dentro de la máquina virtual. No son direcciones de red enrutables reales. El tráfico real de la conexión se proporciona a través del cable virtual.
Para el software que se ejecuta en un dispositivo virtual, los terminales aparecen como host de red nombrados. Una entrada define un nombre de host en el que un servidor como Apache puede estar a la espera de las solicitudes de conexión entrantes. Si una salida se deja sin conectar, aparecerá dentro de la máquina virtual como "host no accesible". Cuando se conecta a una entrada de otro dispositivo, la misma salida actúa como host de red válido, al que se establecen las conexiones. Si inicia sesión en el dispositivo y hace ping a una salida conectada, verá que el nombre de la salida resuelve a la dirección IP de la entrada del otro dispositivo al que está conectada la salida.
Nota: Los terminales eliminan referencias a otros dispositivos y servidores.
El código que se ejecuta dentro de un dispositivo verá una "red" formada solamente por unos cuantos host, uno para cada terminal definido en el límite del dispositivo. De este modo, es posible conectar distintas instancias del mismo dispositivo en distintas estructuras sin modificar la configuración del dispositivo.
Por ejemplo, si va a generar un dispositivo que necesita acceso a un servidor de base de datos, puede definir una salida para acceder a esa base de datos y denominarla DBASE. Al configurar el controlador JDBC dentro del dispositivo, sencillamente establezca el nombre de la salida "DBASE" como nombre de host del servidor de base de datos de destino. En tiempo de ejecución, cada instancia del dispositivo se puede conectar a un servidor de base de datos diferente sin tener que cambiar el nombre de host de destino del controlador JDBC, ya que el mismo nombre de host "DBASE" resolverá automáticamente a la dirección IP correcta del servidor de base de datos al que está conectada la instancia en particular.
Es posible especificar qué protocolos se permiten en cada terminal. De este modo se crea un cortafuegos virtual en el terminal, que deja dentro o fuera solamente los protocolos permitidos. Como ventaja adicional, al configurar la aplicación, CA AppLogic® garantiza que sólo se conecten entre sí los terminales con protocolos coincidentes. De manera que, si el software del dispositivo se configura para que funcione con MySQL a través de la salida DBASE, puede declarar el protocolo de DBASE como MYSQL para impedir que alguien lo conecte accidentalmente a un servidor de Oracle.
Nota: Se puede declarar cualquier terminal como obligatorio, lo que indica a CA AppLogic® que el dispositivo no puede funcionar si no se conecta a este tipo de servicio externo. Si se deja sin conectar un terminal obligatorio, CA AppLogic® rechazará el inicio de cualquier aplicación y le indicará qué terminal ha olvidado conectar.
Cada dispositivo necesita al menos un volumen de almacenamiento, aquel desde el que arranca. Estos volúmenes se proporcionan como parte de la definición de clase del dispositivo y se instancian siempre que se crea una instancia del dispositivo. A menudo, resulta útil definir los dispositivos con marcadores para agregar más volúmenes. Cuando se define un marcador, éste se convierte en una "ranura", en la que más tarde se puede conectar un volumen externo.
Los volúmenes que se pueden "conectar" en una ranura de marcador se conocen como volúmenes de aplicación. Para crear un volumen de aplicación explícitamente, ejecute el comando apropiado y especifique un nombre, el tamaño de almacenamiento y el tipo del sistema de archivos que desee. Se pueden montar volúmenes de aplicación en el controlador de CA AppLogic® para transferir datos dentro y fuera de ellos.
Por ejemplo, resulta útil definir un dispositivo de servidor Web con dos volúmenes, uno de arranque y otro de contenido. El volumen de arranque contiene el software y los archivos de configuración necesarios para arrancar Linux y ejecutar un servidor Web Apache. Este volumen se convierte en parte de la definición de clase y se instancia para cada instancia del dispositivo.
El volumen de contenido, sin embargo, es un marcador para un volumen de aplicación que incluirá los archivos HTML, las imágenes estáticas y los scripts de un sitio Web específico. Al configurar una instancia del dispositivo de servidor Web con una referencia al volumen de contenido, se generará una instancia de un servidor Web Apache que dará servicio al sitio Web en particular. Las páginas y demás contenido para este servidor Web se colocarán en el volumen de contenido.
Sugerencia: Se puede utilizar un solo volumen de aplicación para implementar contenido en varios servidores Web. Una forma sencilla de hacerlo es agregar una propiedad que especifique el directorio base del volumen, desde el que el dispositivo en cuestión accederá al contenido. De este modo resulta fácil configurar varios servidores Web con el mismo volumen de contenido, mientras se configura cada instancia para dar servicio al contenido desde un directorio diferente.
El mismo patrón se puede utilizar para diseñar un servidor J2EE genérico configurado con un volumen (y una ruta base en él) que contenga los paquetes EJB para una función de aplicación en particular, o un servidor de base de datos genérico configurado con un volumen y una ruta que contenga una base de datos específica.
De hecho, si se utiliza esta combinación de volumen de aplicación y una propiedad de ruta de directorio, será posible combinar la interfaz de usuario, el contenido estático, el código y los datos de la aplicación en un solo volumen, lo que facilita la implementación, la modificación y el mantenimiento.
|
Copyright © 2013 CA.
Todos los derechos reservados.
|
|