Professional Documents
Culture Documents
Documentación
Copia nº 00/00
Sistemas
Índice
1 Instalación JBOSS AS 7
Una vez descomprimida la distribución de JBOSS AS7, se deberá decidir si se
quiere trabajar en “modo domain” ó en “modo standalone”. Ver la sección “Modo
Domain vs Modo Standalone”.
Sobre Unix:
$ cd bin
$ ./domain.sh
Sobre Windows:
> cd bin
> domain.bat
En Unix
$ cd bin
$ ./standalone.sh
Sobre Windows:
> cd bin
> standalone.bat
La ejecución de este script creará un único proceso: una única instancia JBOSS AS7
Una instancia arrancada en “modo standalone” puede ser parada de las siguientes
maneras:
$ cd bin
$ ./jboss-cli.sh --connect command=:shutdown
Notice that the command was renamed in AS7.1 in AS7.0 replace the script name
jboss-cli by jboss-admin.
La permutualidad entre modos una vez arrancada una instancia no es posible. Por
ejemplo, no se puede ejecutar el script domain.sh, parar el proceso, y ejecutar el
script standalone.sh
La diferencia entre los modos domain y standalone radica en la manera en que los
servidores serán manejados, no en las capacidades que tienen para servir
requerimientos de usuario. Esta diferencia es particularmente importante cuando se
va a trabajar con clústeres configurados en alta disponibidad. Es muy importante
esta observación porque un grupo de servidores ejecutándose en modo standalone
JBoss AS7: Modo domain 6/77
Sistemas
podrían ser configurados para formar un cluster HA. Los modos domain y standalone
determinan como los servidores serán administrados, no las capacidades que
pueden proporcionar.
3 Contenido de la distribución AS 7.
Lo primero que se observa es que el sistema de ficheros está dividido en dos partes
principales: servidores standalone y servidores domain.
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.0.0.CR2</version>
<licenses>
<license>
<name>GNU Lesser General Public License</name>
JBoss AS7: Modo domain 8/77
Sistemas
<url>http://www.gnu.org/licenses/lgpl-2.1.html</url>
<distribution>repo</distribution>
<comments>See discussion at http://hibernate.org/license for more details.</comments>
</license>
</licenses>
</dependency>
El otro subdirectorio llamado schema contiene ficheros .xsd los cuales son usados
como patrones de configuración.
lib- Alberga el subdirectorio ext, el cual es creado para almacenar las extensiones
Java SE/EE. Algunas de las aplicaciones desplegadas pueden acceder a este
directorio para incluir librerías las cuales pueden ser accedidas por el cargador local
de clases, no obstante esta práctica no es recomendable y es mantenido
data -- información escrita por el servidor para almacenar sus datos en tiempo
de ejecución (por ejemplo, transaction logging).
data – información escrita por el servidor para almacenar sus datos en tiempo de
ejecución, por ejemplo transaction logging.
lib – Contiene el subdirectorio ext, el cuál es usado para definer extensions del
servidor. Las mismas consideraciones hechas para el subdirectorio domain.lib son
válidas aquí.
log – Contiene los logs para la instancia standalone del servidor. El fichero de log
por defecto llamado server.log, es truncado cada vez que el servidor es arrancado.
tmp – usado por Virtual File System del JBOSS como almacenamiento temporal.
4 Conceptos Generales
A continuación se estudian conceptos comunes a los modos “Domain” y
“Standalone”
4.1.1 Extensiones
El servidor contiene una lista de módulos básicos llamados extensiones, los cuales
son compartidos por todos los servicios. Las extensiones pueden ser vistas como un
tipo especial de módulo los cuales son usados para ampliar las funcionalidades del
servidor. Como los módulos estándar, son almacenadas en el directorio
JBOSS_HOME/modules. Cada extensión es detectada por el cargador de clases
del servidor en tiempo de arranque antes de realizar cualquier despliegue.
<extensions>
<extension module="org.jboss.as.clustering.infinispan"/>
<extension module="org.jboss.as.messaging"/>
</extensions>
4.1.2 Paths
Un <path name> es un nombre lógico para los paths del sistema de ficheros. El
siguiente ejemplo, define una path relativo para el directorio log del servidor AS
llamado log.dir, el cuál es traducido por servidores standalone en
JBOSS_HOME/standalone/log/mylogdir.
<paths>
<path name="log.dir" path="mylogdir" relative-to= "jboss.server.log.dir"/>
</paths>
Este path puede ser referenciado en otras secciones del fichero de configuración.
Por ejemplo, podemos usarlo como directorio para el almacenamiento del “logging
rotating file handler”:
<periodic-rotating-file-handler name="FILE" autoflush="true">
<file relative-to="log.dir" path="myserver.log"/>
</periodic-rotating-file-handler>
Path Meaning
jboss.home Directorio raíz de la distribución
JBoss AS
user.home Directorio base de usuario.
user.dir Directorio de trabajo para el
usuario en curso
java.home Directorio instalación del Java
jboss.server.base.dir Directorio raíz para una instancia
individual del servidor
jboss.server.data.dir Directorio usado por el servidor
para almacenar ficheros de datos
persistentes
jboss.server.log.dir Directorio de almacenamiento de
ficheros de log
jboss.server.tmp.dir Directorio de almacenamiento de
ficheros temporales
jboss.domain.servers.dir Directorio bajo el cual un
Controlador de Host creará el área
de trabajo para instancias
individuales del servidor
</socket-binding-group>
4.1.4 Profiles
Es uno de los conceptos principales nuevos en JBoss AS 7. Un profile puede
considerarse como un conjunto de subsistemas: cada subsistema en si mismo tiene
un subconjunto de funcionalidades usadas por el servidor de aplicaciones. Por
ejemplo, el subsistema Web contiene la definición del conjunto de conectores usado
4.1.5 Interfaces
-----------------------------------------------------------------------------------------------------------------
Se pueden cambiar los puertos a los cuales los servicios están asociados mediante
su atributo “port”. Es mejor usar las interfaces de administración que realizan de
manera inmediata el cambio.
En el siguiente ejemplo, se cambia el Puerto por defecto para el conector http
usando el CLI:
[standalone@localhost:9999 /] /socket-binding-group= standard-sockets/socket-
binding=http:write-attribute(name="port", value="8090")
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
APPJAVA="TCORP-MAQUINA1-A"
PORTSAG=9990 # Puerto de la consola http://maquina1.maq.es:9990/console
PID=$(netstat -tuanp | grep -m $PORTSAG | gawk '{ print $7 }' | cut -d "/" -f1)
COINCID=$(ps -ef | grep PID|grep -wo "$APPJAVA")
COINCID1=$(ps -fu `whoami` | grep java | grep -wo "$APPJAVA"|head -1)
export JAVA_OPTS="-Djava.util.Locale=es_ES -Duser.Region=ES -Duser.language=es
-Dfile.encoding=iso-8859-1 -Duser.timezone=UTC
-Dorg.apache.el.parser.COERCE_TO_ZERO=false"
echo
echo "-La de la consolaes --> http://maquina1.maq.es:9990/console" # La consola de
#administración del jboss
echo "-La URL de servicio --> http://maquina1.maq.es:8080/" la url de servicio
echo "-El log es --> /home/jboss/dominios/TCORP/TCORP-MAQUINA1-A/standalone/log/server.log"
echo
export JBOSS_HOME=/home/jboss/jboss-eap-6.1
echo
echo "------ PARANDO TCORP-MAQUINA1-A ----"
echo
$JBOSS_HOME/bin/jboss-cli.sh --connect controller=89.1.5.49:9999 command=:shutdown
.
.
.
.
echo
echo "-La de la consolaes --> http://maquina1.maq.es:10190/console"
echo "-La URL de servicio --> http://maquina1.maq.es:8280/"
echo "-El log es --> /home/jboss/dominios/TCORP2/TCORP2-MAQUINA1-A/standalone/log/server.log"
echo
$JBOSS_HOME/bin/standalone.sh --server-config=standalone-ha.xml
-Djboss.bind.address=89.1.5.49 -Djboss.bind.address.management=89.1.5.49
-Djboss.server.base.dir=/home/jboss/dominios/TCORP2/TCORP2-MAQUINA1-A/standalone
-Djboss.node.name=TCORP2-MAQUINA1-A -Djboss.socket.binding.port-offset=200
>> /home/jboss/dominios/TCORP2/TCORP2-MAQUINA1-A/standalone/log/server.log 2>&1 &
Pulsamos Examinar luego seleccionamos el fichero a desplegar conde lo hayamos dejado en nuestro
PC y pusamos Abrir.
Pulsar Next
Pulsar Save
Pulsamos Confirm
El resultado final
Seleccionar el driver
Meter los datos la URL, usuario y clave, aquí hay un ejemlpo de una url:
jdbc:oracle:thin:@tcorpdes3.maquina2.maq.es:1524:TCORPDS3
Situacion final
start-GSV-SC1108-A.sh
export JAVA_HOME=/usr/java/jre1.6.0_25
export JBOSS_HOME=/home/jboss/jboss-eap-6.1
APPJAVA="GSV-SC1108-A"
# Comprobar si el proceso esta arrancado.
PORTSAG=9990 # Puerto de la consola http://sc1108.sscc.ae.aena.es:9990/console
PID=$(netstat -tuanp | grep $PORTSAG | gawk '{ print $7 }' | cut -d "/" -f1)
COINCID=$(ps -ef | grep PID|grep -wo "$APPJAVA")
COINCID1=$(ps -fu `whoami` | grep java | grep -wo "$APPJAVA"|head -1)
if [ "$COINCID" != "" ] && [ "$COINCID1" = "$APPJAVA" ]; then
echo ""
echo " Se encuentra una instancia activa de $APPJAVA con PID = $COINCID"
echo ""
echo " !!! Primero debe parar esta instancia para arrancar una nueva !!!"
echo ""
exit
fi
if [ "$COINCID1" = "$APPJAVA" ]; then
echo ""
echo " Se encuentra una instancia activa de $APPJAVA"
echo ""
echo " !!! Primero debe parar esta instancia para arrancar una nueva !!!"
echo ""
exit
fi
echo
echo "-La de la consolaes --> http://sc1108.sscc.ae.aena.es:9990/console"
echo "-La URL de servicio --> http://sc1108.sscc.ae.aena.es:8080/"
echo "-El log es --> /home/jboss/dominios/GSV/GSV-SC1108-A/standalone/log/server.log"
echo
$JBOSS_HOME/bin/standalone.sh --server-config=standalone-ha.xml
-Djboss.bind.address=89.1.6.197 -Djboss.bind.address.management=89.1.6.197
-Djboss.server.base.dir=/home/jboss/dominios/GSV/GSV-SC1108-A/standalone
-Djboss.node.name=GSV-SC1108-A -Djboss.default.multicast.address=230.0.0.70 >>
/home/jboss/dominios/GSV/GSV-SC1108-A/standalone/log/server.log 2>&1 &
Una vez que el servidor en modo dominio esta arrancado (domain.sh o domain.bat),
se crean algunos ficheros de log. La actividad (traza) del Controlador de Host será
almacenada JBOSS_HOME\domain\log\host-controller, mientras los logs del Control
de Proceso será almacenado JBOSS_HOME\domain\log\process-controller.
./domain.sh --host-config=custom_host.xml
Cada dominio de servidores puede ser dividido en server groups, cada uno asociado
a profiles diferentes. El concepto de server groups puede ser entendido como un
grupo de servidores pertenecientes a un dominio administrados como una simple
unidad.
Los server groups pueden ser utilizados para optimizar la configuración de nodos,
por ejemplo, cada server group puede definir sus propias características, tales como
ajustes para la JVM, interfaces socket bindings , o aplicaciones desplegadas..
La siguiente figura muestra algunos atributos comunes, los cuales pueden ser
aplicados a un server group:
Según la figura, un dominio puede contener varios hosts (host1, host2) y también
varios grupos. (main server group, other server group). Sin embargo, mientras un
server group es simplemente una asociación lógica de varios nodos que pueden
estar ubicados en cualquier sitio, un host se refiere a un conjunto de nodos
(instancias) que son parte de la misma distribución AS.
El termino host puede tomarse como máquina, si se instala una distribución de AS
por máquina. Esto no siempre es verdad, se pueden instalar varias distribuciones AS
en la misma máquina de tal manera que tendríamos múltiples host en la misma
máquina.
Para completar la definición de hosts, se deben añadir los siguientes grupos de
elementos de dominio:
Las interfaces de administración usadas para administrar el dominio.
Definición del Controlador de Dominio
Las Interfaces de Red donde los services son asociados.
Configuraciones para JVM.
Los servidores que forman parte del dominio.
</interface>
</interfaces>
<socket-binding-group ref="standard-sockets"/>
</server-group>
La definición de una JVM también puede ser asociada a una instancia en particular,
de tal manera que se sobrescriba la definición del server group. Por ejemplo, server-
one (definido en host.xml) hereda la configuración default JVM, actualizando los
atributos custom min (512 MB) y max heap size (1 GB):
<server name="server-one" group="main-server-group" auto-start="true">
<jvm name="default">
<heap size="512m" max-size="1G"/>
</jvm>
</server>
8 Clusterización
En versiones anteriores de JBoss las librerías características del cluster estaban
empaquetadas dentro de la configuración all del servidor, la cual estaba separada
del resto de configuraciones por defecto.
En AS 7 no existen diferentes configuraciones (librerías + ficheros de configuración)
de servidor. Todo lo que hay que hacer para crear un nuevo profile es crear un
nuevo fichero XML de configuración asociado.
El modo standalone usa un único profile, definido en el fichero de configuración
(standalone-ha.xml), el cual contiene todos los subsistemas para la clusterización.
El modo domain puede usar múltiples profiles definidos en el fichero domain.xml, los
cuales pueden ser usados por servidores en modo domain clusterizados y no
clusterizados.
Un error muy común de concepto es equiparar el concepto de domain a un cluster
de nodos, de tal manera que podría ser usado para aportar importantes
características como el balanceo de carga o la alta disponibilidad.
El modo dominio no tiene nada que ver con las funcionalidades que una aplicación
necesite. Está orientado al concepto de administración del servidor de tal manera
que puede ser usado con aplicaciones preparadas para funcionar en cluster y con
aplicaciones que no lo estén.
El modo domain y el Cluster no son mutuamenete excluyentes y a menudo forman
parte del mismo escenario.
En esta sección se van a describir las diferentes maneras de montar y arrancar un
cluster de servidores en modo standalone y en dominio.
En esta sección se procede a configurar los AS7 maestro y esclavos para que todos
se ejecuten en modo dominio. También se configurará el AS7 maestror como
Controlador de Dominio.
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>
<interface name="unsecured">
<inet-address value="127.0.0.1" />
</interface>
</interfaces>
Se debe cambiar la dirección de management interface de tal manera que los AS7
esclavos puedan conectar con el AS7 maestro. La public interface permite que la
aplicación pueda ser accedida vía HTTP no local, y la unsecured interface permite
acceso remoto RMI. La IP del AS7 maestro es 89.1.4.241:
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management: 0.0.0.0}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address: 89.1.4.241}"/>
</interface>
JBoss AS7: Modo domain 44/77
Sistemas
<interface name="unsecured">
<inet-address value="89.1.4.241" />
</interface>
</interfaces>
Ahora se modifica la sección domain-controller de tal manera que los AS7 esclavos
puedan conectar AS7 maestro cuya IP es 89.1.4.241 :
<domain-controller>
<remote host="89.1.4.241" port="9999"/>
</domain-controller>
Finalmente, también es necesario configurar la sección de interfaces y hacer visibles
las direcciones de los AS7 esclavos:
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:89.1.5.17}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address: 89.1.5.17}"/>
</interface>
<interface name="unsecured">
<inet-address value="89.1.5.17" />
</interface>
</interfaces>
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:89.1.4.237}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address: 89.1.4.237}"/>
</interface>
<interface name="unsecured">
<inet-address value="89.1.4.237" />
</interface>
</interfaces>
Esto es debido a que no está configurada la “autentificación” entre los AS7 maestro
y esclavos.
Maestro
En el directorio bin hay un script llamado add-user.sh el cual se usará para añadir
nuevos usuarios al fichero de properties usado para la autentificación del domino:
./add-user.sh
./add-user.sh
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-user.properties)
(a):
Esclavos
<security-realms>
<security-realm name="ManagementRealm">
<server-identities>
<secret value="MTIzMTIz="/>
</server-identities>
<authentication>
<properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/>
</authentication>
</security-realm>
</security-realms>
Los nombres de los host esclavos fueron definidos anteriormente como slave1 y
slave2, y estos mismos nombres deben ser utilizados para acceder al host maestro.
El valor de la propiedad <secret value> es 'MTIzMTIz=', lo cual es la codificación en
base64 para '123123'. Este valor se puede generar usando un generador base64.
<domain-controller>
<remote host="89.1.4.241" port="9999" security-realm="ManagementRealm"/>
</domain-controller>
Esto significa que todo está configurado bien y que además tenemos dos host
esclavos + un host maestro corriendo en modo dominio.
JBoss AS7: Modo domain 48/77
Sistemas
Por defecto (en la figura hay una cuarta) hay tres instancias AS7:
server-one (inactiva)
server-two (inactiva)
server-three (inactiva)
Hay tres hosts constituyendo este server group de tal manera que la aplicación debe
ser desplegada en todos: maestro y esclavos que son los que configuran el dominio.
Maestro http://89.1.4.241:8380
Esclavo 1 http://89.1.4.237:8380
Esclavo 2 http://89.1.4.237:8380
<servers>
<server name="clusterdemo" group="clusterdemo-server-group" auto-start="true">
<socket-bindings socket-binding-group="ha-sockets" port-offset="300"/>
</server>
</servers>
Hasta aquí tenemos los JBOSS AS7 (master + slave1 + slave2) en modo Domain
operativos.
Lo siguiente es la configuración del cluster y por último las pruebas de replicación de
sesión.
El IIS7 escucha en el puerto 80. Comprobar que ningún proceso está escuchando en
él. De estar ocupado habría que cambiarlo vía consola de administración del IIS7.
Se debe crear un directorio virtual cuyo alias es “Jakarta” y que apunte al directorio
donde residen los fichero de configuración del filtro ISAPI ( paso 1).
Cliquear “Agregar”:
Crear una nueva entrada “Jakarta Isapi Redirector” y debajo de esta otra nueva
llamada “1.0” y debajo incluir 6 nuevos valores
worker.list = loadbalancerA,status
worker.default.fail_on_status=404
# Define Slave1
worker.slave1.reference=worker.default
worker.slave1.host = 89.1.5.17
worker.slave1.port = 8309
worker.slave1.redirect=slave2
# Define Slave2
worker.slave2.reference=worker.default
worker.slave2.host = 89.1.4.237
worker.slave2.port = 8309
worker.slave2.redirect=1
# Load-balancing behaviour
worker.loadbalancerA.type=lb
worker.loadbalancerA.balance_workers=slave1,slave2
worker.loadbalancerA.sticky_session=1
# Load-balancing behaviour
worker.loadbalancerA.type=lb
worker.loadbalancerA.balance_workers=slave1,slave2
worker.loadbalancerA.sticky_session=1
.type Puesto que se está hablando de balancear servidores app, deberá ser siempre
“lb”
.balance_workers define los workers a ser balanceados que forman parte del worker
" loadbalancerA".
. sticky_. Esta propiedad especifica el comportamiento para la sesiones HTTP.
Si se especifica worker.loadbalancer.sticky_session=0, cada requerimiento será
dirigido (balanceado) entre slave1 y slave2; por ejemplo diferentes requerimientos
para la misma sesión irán a servidores diferentes. Pero cuando un usuario abre una
sesión sobre un servidor, todos sus requerimientos serán dirigidos al mismo
servidor, siempre y cuando esté disponible. Este tipo de comportamiento es
conocido como “sticky session”, cada cliente es siempre redirigido al servidor que se
/cluster-demo=loadbalancerA
/cluster-demo/*=loadbalancerA
<system-properties>
<property name="java.net.preferIPv4Stack" value="true"/>
<property name="jvmRoute" value="slave2"/>
<property name="UseJK" value="true"/>
</system-properties>
…………
<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host"
native="false" instance-id="${jvmRoute}">
<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
<system-properties>
<property name="java.net.preferIPv4Stack" value="true"/>
<property name="jvmRoute" value="slave1"/>
<property name="UseJK" value="true"/>
</system-properties>
…………
Para ello utilizar los scripts de arranque / parada del servidor del que se trate:
Accedemos al cluster:
http://ssccptpresta13:8090/cluster-demo/put.jsp
El requerimiento debería ser despachado por uno de los dos host esclavos (slave1 o
slave2). En este caso el requerimiento fue enviado al host slave2 (sc1032):
http://ssccptpresta13:8090/cluster-demo/get.jsp
El requerimiento get.jsp debería proporcionar la misma hora que puso vía put.jsp.
Esto verifica que la sesión es correctamente replicada en el otro host (slave1)