Tomcat y enlaces simbólicos

Esta semana pusimos una aplicación Java bajo Tomcat 5.0 en alta disponibilidad. Para ello, la aplicación necesita usar un sistema de archivos compartido, que configuramos mediante NFS remoto. Los directorios donde se guardan los ficheros compartidos caen dentro del contexto de la aplicación, por lo que decidimos sacarlos al directorio NFS, y en su lugar dejar enlaces simbólicos. El problema que sucede entonces es que a Tomcat (igual que Apache) tenemos que decirle que siga los enlaces simbólicos.

Esto se le puede decir con el atributo allowLinking="true" en la etiqueta <context>, que encontraremos de forma aislada en el fichero XML del contexto de nuestra aplicación, dentro de los subdirectorios conf/Catalina/localhost/ o conf/Standalone/localhost (según hayamos definido el Engine en server.xml), o bien el en el propio conf/server.xml, dentro de <Server><Service><Engine><Host>

<context path="/mi-aplicacion" 
         docBase="DIRECTORIO_de_mi_aplicacion"
         allowLinking="true"/>

Evento Citrix en Murcia

Hace unas semanas estuve en un evento que Citrix celebró en Murcia. Estuvo organizado por el grupo inforges y resultó muy interesante porque pudimos descubrir cómo Citrix ha re-bautizado sus productos tras la adquisición de XenSource y Ardence, y encontrar las analogías con lo que conocemos del mundo VMware.

1. XenServer se correspondería con VMware ESX Server. Dispone de hasta cuatro versiones de licenciamiento. XenServer Express Edition es gratuito hasta 4 máquinas virtuales corriendo en un único servidor. En la Enterprise Edition hay disponible un XenMotion (equivalente a VMotion).
2. XenCenter se correspondería con VMware VirtualCenter.
3. XenConvert se correspondería con VMware Converter. Este producto permite virtualizar equipos, generando una imagen .XNA que luego podemos importar desde XenCenter.
4. Citrix Provisioning Server, es lo que llaman Streaming de Sistema Operativo, y al final consiste en una herramienta para poder desplegar el sistema orativo como hace Altiris Rapid Deployment Pack vía PXE entre otros.
5. XenApp es la suite clásica de productos Citrix (ICA) que ya conocíamos (Metaframe, SecureGateway, etc) que han provisto además de posibilidades para el streaming de aplicaciones (lo que hace SoftGrid de Microsoft) o virtualización de aplicaciones. Resultó interesante ver un vídeo que demostraba como el protocolo RDP6 de Micrsoft aún tiene mucho que mejorar para hacer sombra a ICA, sobre todo bajo conexiones lentas

De pasada me quedé con las herramientas libres de inventario que están pegando duro: GLPI que están poniendo en marcha en la Consejería de Hacienda, y OCS Inventory que estamos poniendo en marcha en la Consejería de Educación.
En lo que se refiere a la virtualización del escritorio XenDesktop (se apoya en ActiveDirectory, igual que hace VDI de VMware, y sólo podemos usarlo bajo Windows 2003) presentaron los cuatro formatos en las que lo encontramos (Express, Platinum, Standard, Enterprise): La edición Express permite 10 hasta usuarios de forma gratuita. La Enterprise incorpora licencias de XenApp (lo que sería el Presentation Server) de forma que nos permite degustar los dos sabores, para pode determinar qué es mejor: si virtualización de escritorios o de aplicaciones. XenDesktop se fundamenta en portICA que es un protocolo distinto a ICA, que está en pleno desarrollo y que sólo permite virtualizar escritorios Windows XP, Vista y 2008.

VMware VMotion entre CPUs diferentes

Hace una unas semanas configuramos en un cliente VMware VirtualCenter 1.3 sobre los dos servidores ESX que tenía instalados. Estos servidores eran un IBM xSeries 346 y un 345, prácticamente con el mismo hardware pero diferían en el modelo de CPU: Uno llevaba un intel xeon 3.2GHz y el otro iba con un intel xeon 2GHz.

Cuando lanzábamos el live-migration de vmotion en caliente nos encontrábamos que no podíamos hacerlo, y nos daba un el error:

Error: Cannot migrate between hosts with different CPUs. Supported extended features differ. (Source: 0x00000000, Destination: 0x0000001d)

En los foros de VMware existen diferentes soluciones, pero probablemente ninguna se ajuste a lo que necesitamos. El documento que mejor explica este problema lo encontramos en VMotion CPU Compatibility - Migrations Prevented Due to CPU Mismatch - How to Override Masks, donde comenta que todo se debe a un problema máscaras de bits, por lo que las soluciones que a otras personas les funcionaron, no tienen por qué servirnos.

Lo que tendremos que hacer, es ejecutar el comando cat /proc/vmware/cupinfo y observar la salida, y buscar el campo al que hace mención el error (Supported extended features differ), que en nuestro era extFeat: Para un nodo valía 0x0000441d, y para el otro 0x00004400, que al hacer un OR-Lógico nos devolvía el error que estábamos obteniendo: 0x0000001d. En ese momento calculamos la máscara que tendríamos que aplicar para que al hacer el XOR-Logico el resultado fuera 0x00000000. En nuestro caso, la máscara que probamos nos funcionaba fue: 0xE5FF.

Una vez tenemos la máscara, debemos crear el fichero C:\Documents and Settings\All Users\Datos de programa\VMware\VMware VirtualCenter\config.ini con el siguiente contenido:

migrate.ignore.extfeature.bits = 0xE5FF
migrate.ignore.feature.bits = 0x20000

, reiniciar el servicio VirtualCenter y volver a probar el live-migration.