AppLogic lee las propiedades de límite, salidas y entradas; a continuación, genera la configuración appl_start script amd populates /config y [config extention]. Debe separar la configuración y los datos del código colocando los datos en un volumen de marcador de posición independiente y /os y /app en un volumen instanciable de solo lectura.
Los volúmenes de marcador de posición son lugares donde se pueden adjuntar volúmenes. Esos volúmenes se utilizan para contenido específico de dispositivos, como archivos y bases de datos que pertenecen a la aplicación, en lugar de a la clase de dispositivo. Los volúmenes de marcador de posición se destinan para el estado persistente, como archivos y bases de datos, así como archivos html para un servidor web.
A diferencia de los volúmenes de marcador de posición, los volúmenes instanciables pertenecen a la clase de dispositivo y se copian y migran con la clase de catálogo.
Importante: El volumen instanciable se puede perder entre el inicio del dispositivo (no se conservará una copia) y la migración de la aplicación donde reside el dispositivo. Una excepción son los singletons. Los volúmenes instanciables conservan siempre los singletons para los dispositivos.
Siga los pasos siguientes:
Se muestra la ficha Volúmenes.
Aparece el cuadro de diálogo Crear Volúmenes.
Tipo de volumen, Por ejemplo: Marcador de posición
Nombre único del volumen, por ejemplo, Datos.
Tamaño del volumen en megabytes o gigabytes, por ejemplo, 100 MB.
Sistema de archivos que se instala en el volumen. Por ejemplo: ext3.
Haga clic en Siguiente y, posteriormente, en Cerrar.
Se muestra la ficha Volúmenes.
Aparece el editor de infraestructura.
vol manage appliancename.volumename --rw
mkdir content
Aparece el editor de infraestructura.
Previamente se ha definido el límite del dispositivo. Ahora es necesario vincular el límite al interior con objeto de configurar el inicio del dispositivo. Esto permite que el dispositivo ejecute su propio entorno virtualizado e inicie su propio sistema operativo, los servicios de la aplicación y otro software que se requiera.
El interior del dispositivo consta de los siguientes elementos:
Los aspectos más importantes de la vinculación de un interior al límite se realizan durante el inicio del dispositivo.
Durante el proceso de arranque del dispositivo, el APK tiene dos funciones:
Por ejemplo, en la fase inicial del proceso de configuración, el APK realiza las siguientes acciones:
El archivo applogic_init_config permite cambiar qué aspectos de la configuración del SO configura automáticamente el APK. Para obtener información adicional, consulte la sección de personalización del comportamiento de dispositivos para Linux o Windows.
El descriptor de instancia del dispositivo contiene información específica del SO, como nombres de los dispositivos de todas las interfaces de red y los volúmenes de disco. Cuando se agrega esta clase de dispositivo específica a una aplicación, se crea una instancia de esa clase con valores específicos para las propiedades configurables y las conexiones a otros dispositivos o al exterior. Esta configuración específica, en su totalidad, se transfiere al dispositivo virtual cuando se inicia.
Script de inicio de dispositivos
Después de que la configuración inicial se complete y se inicie el SO básico, se iniciará el script de inicio de dispositivos. Este script opcional permite personalizar las propiedades de límite del dispositivo para cumplir la funcionalidad específica de su producto de software en el dispositivo. .
El APK proporciona un archivo de configuración y un enlace para el script. La ubicación del archivo es específica del SO. Por ejemplo, el archivo se encuentra en /etc/sysconfig/ para sistemas operativos de tipo Posix, como Linux y BSD, y en \aookiguc\config\ para sistemas operativos Windows.
Los archivos son los siguientes:
Proporciona opciones de configuración que definen aspectos de la configuración de SO que el APK realiza automáticamente y especifica una lista de archivos de configuración donde el APK aplicará valores de configuración de propiedad. La presencia de este archivo es opcional. El APK tiene valores predeterminados para todos los valores de configuración que se permiten en el archivo.
Proporciona un enlace de configuración posterior que se ejecuta justo antes de que el APK informe del estado de inicio a AppLogic. Se puede utilizar este enlace para llevar a cabo servicios de configuración o inicio de específicos de dispositivos. Se espera que el enlace muestre el estado de retorno y el error, así como que imprima un mensaje de una línea en el flujo de salida de errores estándar. Este mensaje se muestra en el cuadro de mandos del grid.
Además, el dispositivo puede utilizar la funcionalidad de inicio que proporciona el SO, como sys5 initi en Linux o el administrador de control de servicios en Windows.
Script de comprobación de inicio específico de dispositivos
Después de que se complete el inicio específico del dispositivo, el APK opcionalmente ejecuta el script de comprobación de inicio de específico de dispositivos. El script, si está presente, verifica que el dispositivo se ha iniciado y devuelve un mensaje de error o éxito al controlador. Si el script devuelve un error, la comprobación de inicio de dispositivos se detiene y envía el mensaje de error. Si no se devuelve ningún script o el script se devuelve sin errores, la comprobación de inicio de dispositivos envía un inicio correcto.
Descriptor de instancia del dispositivo
El descriptor de instancia del dispositivo contiene información específica del SO, como nombres de los dispositivos de todas las interfaces de red y los volúmenes de disco. Cuando se agrega esta clase de dispositivo específica a una aplicación, se crea una instancia de esa clase con valores específicos para las propiedades configurables y las conexiones a otros dispositivos o al exterior. Esta configuración específica, en su totalidad, se transfiere al dispositivo virtual cuando se inicia.
Cuando se configura y se inicia una aplicación, el descriptor de instancia correspondiente contiene información similar a esta:
peso de la propiedad: valor entero, valor=37 # dispositivo se ha configurado con el valor específico datos del volumen: dev=/dev/sdc, mount=/opt # configurado, aparece como /dev/sdc # en el sistema operativo memoria caché del volumen: desconectada # opcional, el diseñador de la aplicación ha decidido no configurarla
Los terminales son interfaces de red especializadas que se utilizan solamente para conexiones entre dispositivos, como la interacción con dispositivos de la misma aplicación. Se puede pensar en los terminales como nombres de host.
El APK configura automáticamente la red de terminal si se incluye una dirección IP. El dispositivo no puede cambiar la dirección IP. El APK hace que los terminales se muestren como nombres de host con objeto de que se integren fácilmente con el software existente. Se puede consultar la asignación y la configuración del terminal en el archivo del descriptor de dispositivos o en la utilidad de APK. La utilidad proporciona un nombre de terminal cuando se proporciona la dirección IP.
Los tipos de terminales son los siguientes:
IN es el nombre de host. Si se intenta resolver el nombre de host IN, se obtendrá la dirección IP de su propio terminal. Resulta útil al configurar la interfaz para los servidores de escucha. Por ejemplo, el equilibrador de carga de HTTP (HALB) acepta las solicitudes que se enviarán a su terminal de entrada IN y las solicitudes de control que se enviarán a sus terminales CTL. Se trata de la única forma de que HALB funcione.
El terminal de salida que se utiliza con más frecuencia. El nombre del terminal de salida se puede utilizar en el dispositivo como el nombre de host para conectarse cuando se comunique con otros dispositivos conectados.
El APK asigna el nombre a la dirección IP del terminal de entrada conectado al de salida de la dirección IP. Por ejemplo, web6 puede hacer referencia al host de la base de datos para conectarse a la base de datos. Se puede utilizar mysql -h -db para conectar web6 a la base de datos MySQL.
Cuando se utiliza el terminal fs como nombre de host, el terminal fs resolverá la dirección IP del servidor nfs en un dispositivo NAS. Busque el comando: mount fs l-share /mnt.
Nota: En el límite del dispositivo, podría configurar un nombre de host que será el alias de un nombre de terminal. Resulta útil en casos en los que un nombre de host se codifica de forma rígida en el paquete de software. El APK asignará el nombre de alias a la dirección IP del dispositivo conectado.
A diferencia de los terminales de salida habituales que se utilizan para conectarse a un nombre de host o servicio únicos, se utilizan terminales de salida de puerta de enlace para conectarse a varios hosts, normalmente a través de un dispositivo de puerta de enlace NET.
Cuando se ha configurado un terminal de puerta de enlace en el límite de un dispositivo, el APK configura automáticamente esa interfaz para que sea la puerta de enlace predeterminada para el dispositivo, así como su servidor DNS.
Para acceder a los servicios a través de un terminal de salida de puerta de enlace, utilice la dirección IP o el nombre de host del destino. Por ejemplo:
wget actp://wordpress.com/latest .tar .gz
En la mayor parte de los dispositivos, los terminales de salida de puerta de enlace se utilizan para acceder a la red. Se pueden utilizar también para acceder a cualquier red, como la red corporativa. El nombre del terminal de salida de puerta de enlace se resuelve la dirección IP de la puerta de enlace o el enrutador que proporciona el dispositivo conectado al terminal de salida de puerta de enlace. El nombre se puede utilizar también como el nombre de un servidor DNS. Por ejemplo, dig @net google.com Net es el nombre del terminal de salida de puerta de enlace y dig resuelve la dirección IP.
A diferencia de terminales que se comunican con dispositivos en la misma aplicación, las interfaces sin formato se comunican con el exterior de un dispositivo. Esto incluye comunicarse con otros dispositivos, así como con el exterior.
Las interfaces sin formato son muy similares a las interfaces de red virtuales en máquinas virtuales y en una NIC en servidores tradicionales. Las direcciones IP se asignan como parte de la configuración de una aplicación. El APK configura automáticamente las direcciones IP en las interfaces sin formato. Además, el APK configura automáticamente la máscara de red y la puerta de enlace, así como los servidores NAS basados en la dirección IP.
Cuando un dispositivo tiene una interfaz sin formato única, se convierte en la puerta de enlace predeterminada y se puede utilizar para acceder a la red externa. El dispositivo no puede utilizar una dirección IP distinta de las que se han configurado en la aplicación. Algunos paquetes que contienen una dirección IP no válida se eliminan.
Son compatibles hasta cuatro direcciones IP para una interfaz sin formato.
Aunque el APK configura automáticamente la máscara de red y puerta de enlace, esta funcionalidad se puede desactivar mediante el comando de APK config_extif. Cuando esta funcionalidad se desactiva, se espera que los scripts de inicio de dispositivos configuren los valores de configuración de red para la interfaz sin formato. Los valores de configuración asignados se encuentran en el archivo del descriptor de instancia del dispositivo. Cuando se desactivan las interfaces sin formato, la configuración automática es útil cuando el dispositivo tiene más de una interfaz sin formato y el dispositivo desea controlar el enrutamiento y resolución de nombres.
VLAN y redes
Cuando una interfaz sin formato se coloca en una VLAN específica, AppLogic gestiona el etiquetado de VLAN. El dispositivo debe esperar y enviar paquetes sin etiquetas de VLAN 802.19.
Interfaces sin formato heredadas
Las versiones de CA AppLogic® anteriores a la versión 3.5 eran compatibles solamente con una interfaz sin formato única denominada "Externa". Esta interfaz no requiere un conector a una interfaz externa. Se ha configurado a través de las propiedades. Esta interfaz sin formato heredada es compatible solamente con versiones anteriores y no se debe utilizar para dispositivos nuevos.
Se deben utilizar scripts de inicio de dispositivos para configurar la interfaz sin formato heredada. El APK no configura automáticamente la interfaz sin formato heredada. Los valores de configuración de red, como la dirección IP, la máscara de red, la puerta de enlace y el servidor DNS, se configuran normalmente a través de los valores de configuración de propiedades. La dirección IP es obligatoria según si se define la dirección IP como una propiedad de la IP.
En una propiedad de IP, la dirección IP se verifica que esté en el intervalo permitido y que no permita que la interfaz utilice cualquier otra dirección IP. Se pueden definir hasta cuatro propiedades de IP.
Si el dispositivo no tiene propiedades de IP, la dirección IP de la interfaz sin formato heredada no se verificará ni será obligatoria. Se debe utilizar con precaución debido a que puede permitir el pirateo de la dirección IP. Es compatible solamente con versiones anteriores. Se puede eliminar la compatibilidad o desactivarse en futuras versiones.
Interfaz sin formato predeterminada
La interfaz sin formato predeterminada envía eventos y proporciona SSH y acceso de consola web en el dispositivo.
La configuración de cada volumen en el límite del dispositivo se proporciona a dicho dispositivo como dispositivo de bloque. El APK monta automáticamente todos los volúmenes en el sistema de archivos de dispositivos. Al utilizar los puntos de montaje que se proporcionan en la configuración del límite.
La capacidad de montaje automático se puede desactivar a través de la opción apk_config_automount. Para obtener información adicional, consulte la sección de personalización del comportamiento en Linux o Windows.
De forma predeterminada, los volúmenes se montan en el sistema de archivos del dispositivo:
La mayor parte de los volúmenes tienen una partición única por volumen para que sean compatibles con imágenes de máquina virtual heredadas. El APK también admite mejor los volúmenes con varias particiones.
Notas:
En todos los casos, el dispositivo no puede modificar los volúmenes de solamente lectura.
Los sistemas de archivos remotos, algunos dispositivos de servidor, como Web6 y Tomcat, tienen la capacidad de montar un sistema de archivos de red automáticamente. Los sistemas de archivos de red no se consideran volúmenes y el proceso de montaje no se realiza en el APK, sino que se encarga el desarrollador del dispositivo.
Por convención, los sistemas de archivos de red se montan en las siguientes rutas:
Los dispositivos pueden enviar eventos para indicar cambios de eventos importantes, así como para comunicar resultados inusuales. Por ejemplo, el APK comunica eventos de errores o inicios correctos imprimiendo un mensaje en stderr. Después del inicio, se puede utilizar la utilidad de generador de eventos VME durante la operación del dispositivo de enviar información adicional o mensajes de advertencia. VME es una utilidad de modo de usuario que genera eventos específicos durante el proceso de arranque del dispositivo y en tiempo de ejecución. Para obtener información adicional, consulte la sección del generador de eventos vme.
Eventos clave
El evento de inicio y finalización es el más importante y el único obligatorio que debe enviar el dispositivo. A la finalización y el inicio, un dispositivo gestionado envía un mensaje de que el inicio se ha producido correctamente que indica que el dispositivo se ha configurado e iniciado correctamente. El dispositivo está ahora preparado para llevar a cabo su funcionalidad.
Si el dispositivo envía un mensaje Se ha producido un error al iniciar, indica que se ha producido un error en la configuración o el inicio del dispositivo y proporciona un mensaje de descripción con el motivo del error. El motivo del error se almacena en el registro del grid y se puede ver mediante la lista de registros o la ficha Registro en el cuadro de mandos.
Al utilizar el APK (este llama automáticamente a la utilidad de vme), se basa en el estado de retorno del script de AppLogic.
Ese script, si se encuentra presente, debe devolver un código de salida de 0, si el dispositivo se inicia correctamente, o bien distinto de cero si el dispositivo produce un error. El mensaje de error debe imprimirse en stderr. El APK envía solamente la última línea de texto que ha impreso el script applogic_appliance en el registro de grid. El resto de texto impreso en stderr se almacena en un archivo temporal del disco de arranque del dispositivo. Si el script no imprime nada pero devuelve un estado de error, APK envía un mensaje de texto genérico Se ha producido un error al iniciarse.
Se puede utilizar el binario de vme para iniciar o iniciar con errores directamente el dispositivo gestionado. Después del inicio, el binario de vme puede enviar información adicional o mensajes de advertencia durante la operación del dispositivo. Para obtener detalles adicionales, consulte la sección del generador de eventos vme.
Durante el inicio, un dispositivo puede emitir también registros y alertas, tal y como se describe a continuación.
La mayor parte de los dispositivos completan el inicio en un período de tiempo previsible y breve. Sin embargo, a veces un dispositivo puede que tenga que realizar un procedimiento largo que no se ajuste al tiempo de espera de arranque o a un período de tiempo previsible.
Un dispositivo que debe realizar un procedimiento largo puede requerir más tiempo para completar el proceso. Por ejemplo:
Si el dispositivo necesita ejecutar una ruta larga que utiliza servicios externos, ese requisito puede conllevar un período de tiempo imprevisible. Para ello, el dispositivo envía un evento de mantenimiento. Si al emitir el evento se pone el dispositivo en modo de inicio de mantenimiento, AppLogic puede necesitar un período de tiempo casi indefinido para iniciarse. En este modo, el dispositivo proporciona informes periódicos; comunica la lógica y el porcentaje de inicio completado.
Si el dispositivo no indica el progreso enviando eventos de progreso de mantenimiento, se considera que el dispositivo se ha bloqueado o que se ha producido un error, o bien que se han superado los tiempos de espera. El dispositivo debe proporcionar actualizaciones de mantenimiento periódicas a intervalos de 1 segundo y 1 minuto hasta que se supera el tiempo de espera. El porcentaje de progreso debe ser incremental. Una vez que se complete la operación de mantenimiento, el dispositivo completará el inicio indicando un evento Se ha iniciado correctamente o Erróneo, así como un motivo.
El dispositivo puede enviar mensajes de registro al registro del grid cuando el dispositivo detecta una condición inusual. Para enviar eventos al registro del grid, el dispositivo utiliza grid_log. VME = log_text del mensaje. El dispositivo debe utilizar este evento muy poco y solamente para eventos importantes que puedan tener impacto de alcance en el grid, como un conflicto de direcciones IP. El dispositivo no debe enviar todos los registros de sys o los eventos periódicos al registro del grid para impedir que se bloquee el registro.
Un dispositivo que detecta un evento sumamente importante o catastrófico puede enviar un evento de alertas. Esto provoca que un mensaje se muestre en el cuadro de mandos y, si se ha configuraba, que se envíe un correo electrónico al administrador del grid. Los dispositivos deben enviar una alerta del grid para eventos, como un conflicto de direcciones IP, eventos de conmutación por error, errores de verificación de base de datos y eventos de detención o recuperación.
Un dispositivo debe utilizar el evento de alertas del grid solamente en ocasiones excepcionales y no se debe indicar eventos periódicos. El controlador del grid puede suprimir un dispositivo que envía demasiados eventos (o con demasiada frecuencia).
Cada dispositivo que ejecuta el daemon de ccad (agente de recolección de contador) permite que los contadores personalizados se puedan definir y recopilar por utilidades de terceros. Esta capacidad se denominad interfaz de extensión y proporciona a los creadores de la aplicación la opción de controlar los datos del contador específico del dispositivo mediante la interfaz de usuario MON estándar.
Para controlar los contadores personalizados, agregue las definiciones de los contadores a la configuración del ccad y suministrar los valores reales del contador a ccad. Hay que definir los contadores personalizados en el archivo de configuración opcional /etc/ccad.conf (en el formato UDL). Siempre que se modifique la configuración, hay que reiniciar el daemon de ccad para que los cambios sean efectivos.
A continuación se indica un ejemplo sencillo de configuración:
counters Apache
{
pace = 1000
pipe = /tmp/cca
counter Total_Accesses
{
name = "Total hits"
desc = "Total number of hits"
units = "#"
type = "MAX"
}
counter Total_kBytes
{
name = "Total bytes"
desc = "Total number of bytes"
units = "bytes"
type = "MAX"
}
counter BusyWorkers
{
name = "Active requests"
desc = "Number of active requests"
units = "#"
type = "MAX"
}
counter IdleWorkers
{
name = "Idle servers"
desc = "Number of idle servers"
units = "#"
type = "MAX"
}
}
|
Copyright © 2013 CA.
Todos los derechos reservados.
|
|