IIS que redirecciona a Apache

[secol_FETT]

esto te puede servi, si te falta algun archivo mandame un mp o un correo

parte1

CONFIGURACIÓN DE TOMCAT CON IIS

Este documento explica como hacer que IIS conviva con Tomcat.
Normalmente IIS no puede ejecutar Servlets y JSP (Java Server Pages).
Configurando IIS para usar el plugin redireccionador de Tomcat se le permitirá al IIS enviar peticiones de Servlets y JSP al servidor Tomcat, y de esta manera servir a los clientes.

Convenciones
Sea <tomcat_home> el directorio raíz de Tomcat. La instalación de Tomcat debe generar los siguientes directorios:
1. <tomcat_home>\conf - Directorio con archivos de configuracion
2. <tomcat_home>\webapps - Contiene aplicaciones de ejemplo
3. <tomcat_home>\bin - Lugar donde se ubican los plugins del servidor

En este documento se supondrá que <tomcat_home> es c:\jakarta-tomcat-3.2.3

Definición
Un worker se define como un proceso de Tomcat
Se utilizará un worker que aceptará trabajo desde el servidor IIS.

Requerimientos
El redireccionador IIS-Tomcat fue desarrollado y probado en:
• WinNT4.0-i386 SP4/SP5/SP6a y Win98
• IIS4.0 y PWS4.0
• Tomcat3.0 - Tomcat3.2
El redireccionador utiliza ajp12 para enviar peticiones a los contenedores de Tomcat.

Instalación
El redireccionador de Servlets requiere 3 archivos:

1. isapi_redirect.dll El plugin para IIS
2. workers.properties Un archivo que define el servidor y el puerto usado por los procesos de Tomcat. Un ejemplo de workers.properties puede ser encontrado en c:\jakarta-tomcat\conf
3. uriworkermap.properties Un archivo que mapea URL y Paths a los workers , es decir, registra los contextos (directorios virtuales) y su asociación con un worker, el worker por defecto es ajp12


¿QUÉ ES UN WORKER?

Un worker de Tomcat es un objeto de Tomcat que está esperando a ejecutar servlets a petición de un Servidor Web. Por ejemplo, podemos tener un servidor Web como Apache que redirige peticiones de servlet a procesos Tomcat (los workers) corriendo detrás de él.

El escenario descrito es bastante simple, de hecho uno puede configurar múltiples workers Tomcat para servir servlets a petición de un cierto servidor Web. Las razones para tal configuración pueden ser:

1. Necesitamos que diferentes contextos sean servidos por diferentes workers de Tomcat para proveer de un ambiente de desarrollo donde todos los desarrolladores comparten un mismo servidor web pero cada uno tiene un worker propio.
2. Necesitamos servir diferentes hosts virtuales servidos por procesos Tomcat diferentes para proveer de una clara separación entre sitios pertenecientes a distintas compañías.
3. Necesitamos proveer balanceo de carga, que implica ejecutar múltiples workers de Tomcat cada uno en una máquina propia y distribuir las peticiones entre ellos.

Pueden haber aún más razones para tener múltiples workers, pero estas son las principales.


Configuración de Workers

Los workers de Tomcat están definidos en un archivo workers.properties.
Primero, este archivo contiene una lista de todos los workers que se utilizarán.

worker.list=nombre_worker1, nombre_worker2, ....

ejemplo:
worker.list=ajp12, ajp13

worker.ajp12.port=8007
worker.ajp12.host=localhost
worker.ajp12.type=ajp12

worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
worker.ajp13.lbfactor=1
#crea un worker de tipo loadbalancer y no se pone en la lista inicial
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=ajp12, ajp13


Luego, para cada worker se debe definir el tipo de worker, este tipo se refiere al protocolo de comunicación entre el Worker y el Servidor Web con que se realiza la comunicación (Apache, IIS, etc.)


El tipo de un worker se define como:

worker.<nombre del worker>.type=<tipo del worker>



Los tipos permitidos son:

ajp12 : Utiliza el protocolo ajpv12 para comunicarse con el servidor
ajp13 : Utiliza el protocolo ajpv13 para comunicarse con el servidor
jni : Utilizado para contenedores in-process (workers dentro de Tomcat)
lb : Worker para el balanceo de carga.

POR DEFECTO, Tomcat trae definidos en su archivo workers.properties, 4 workers, uno de cada tipo, cuyos nombres son ajp12 (tipo AJP12), ajp13 (tipo AJP13), loadbalancer (tipo LB), inprocess (tipo JNI).


Worker tipo ajp12
Estos workers se comunican utilizando el protocolo AJPV12 sobre sockets TCP/IP.
Cada worker de este tipo puede configurarse con las siguientes 3 propiedades:

port: puerto donde escuchará peticiones ajp12. Ejemplo: worker.miworker.port=8007

host: máquina donde el worker escucha peticiones. Ej.: worker.miworker.host=localhost

lbfactor: factor de carga, utilizado cuando se utiliza un worker de balanceo de carga. El factor de carga debe ser un numero real mayor que cero.
Ejemplo: worker.miworker.lbfactor=2.5



Worker tipo ajp13
Estos workers se comunican utilizando el protocolo AJPV13 sobre sockets TCP/IP.
Las principales diferencias con ajp12 son que:

1. ajpv13 es un protocolo más binario y trata de comprimir algunos de los datos de la petición codificando string usados frecuentemente como enteros pequeños.
2. ajpv13 reutiliza sockets abiertos y los deja abiertos para peticiones futuras.
3. ajpv13 tiene un tratamiento especial para información SSL, para permitir conexiones seguras.

Cada worker de este tipo puede configurarse con las mismas propiedades que ajp12, pero además tiene la siguiente propiedad:

cachesize: especifica el número de conexiones abiertas (sockets) que este worker mantendrá. Ejemplo: worker.miworker.cachesize=30


Balanceo de Carga
Para utilizar el balanceo de carga, se necesita definir un worker del tipo lb (load balancing).
Este worker no se comunica realmente con workers de Tomcat; en vez de eso es responsable por la administración de varios workers reales. Esta administración incluye:

1.- Instanciar los workers en el servidor web
2.- Usar el factor de balanceo de los workers, realizar operaciones de ponderación y rondas de utilización para balanceo de carga donde EL FACTOR DE CARGA MAS ALTO SIGNIFICA UNA MÁQUINA MÁS PODEROSA (que implica que puede manejar más peticiones)
3.- Mantener las peticiones pertenecientes a una misma sesión ejecutándose en un mismo worker de Tomcat.
4.- Identificar workers de Tomcat que han fallado, suspender peticiones a ellos y redirigir las peticiones a otros workers.

El resultado final es que los workers administrados por el mismo worker de balanceo son balanceados en su carga y los que se han caído o fallado, no implican una caída del sitio completo.



La única propiedad del worker de balanceo de carga es:

balanced_workers: una lista separada por coma de los workers que el balanceador de carga necesita administrar. Este worker (el balanceador) no debe aparecer en la propiedad worker.list.

Ejemplo:

worker.loadbalancer.balanced_workers=ajp12, ajp13