Cloud gaming. Mucha gente habla de cloud gaming... pero ¿qué es exactamente el cloud gaming?
Cloud gaming o videojuego en la nube, es un sistema por el cual un videojuego no se ejecuta en tu máquina local, si no en "la nube", o más bien en los servidores de un tercero, de forma que desde el lado del cliente no se necesita capacidad de cómputo ni cálculo (en resúmen, ninguna máquina potente) para poder disfrutar de los mismos.
Obviamente, esta sesión de juego tiene que llegar al cliente de alguna forma, normalmente en streaming de audio y video (esto es, como si fuera una película), pero con la particularidad de que la comunicación no es solo descendente (desde el servidor a tu sistema), si no también ascendente, porque hay que enviar los comandos de entrada del juego (mando, teclas, etc) hasta el servidor remoto. Básicamente, esto es el cloud gaming.
¿Qué ventajas reporta el cloud gaming? Muchas y variadas, algunas entraré a enumerarlas.
Desde el punto de vista del usuario:
- No se necesita una máquina potente para disfrutar de un videojuego. De eso se encarga la nube. De esta forma puedes disfrutar del último videojuego disponible que requiere muchísima CPU, RAM y demás en un ordenador viejo, en una consola de sobremesa, en un móvil, en un tablet o incluso en un descodificador de vídeo IPTV como los que muchos tenemos en casa para ver la televisión de pago.
- Puedes disfrutar de los videojuegos independientemente de tu plataforma. Esto es, si tienes un tablet pero te gusta los juegazos de PC, vas a tener posibilidad de jugarlos a pesar de que estés en un sistema operativo Android (si hay cliente para ello, claro). O si tienes un MAC, podrás jugar a la última versión del FIFA que no ha salido para el ecosistema Apple.
- Vas a tener acceso a un catálogo de juegos extenso, dado que normalmente no vas a comprar un juego, si no a suscribirte a un servicio. Imaginate un Netflix pero para juegos.
Desde el punto de vista del publisher (del fabricante de videojuegos)
- Vas a poder dar salida a tu catálogo de videojuegos de hace unos años y que ya nadie te compra. Nuevamente imagínate Netflix...
- Vas a distribuir en un entorno donde la piratería NO EXISTE NI PUEDE EXISTIR. Nadie va a descargar nada, y controlar un servicio bajo demanda es muy sencillo.
Desde el punto de vista de un proveedor de servicio (pueda ser una telco, etc)
- Vas a ofrecer un servicio de valor añadido y alta demanda de recursos y calidad sobre tu conexión a internet de alta velocidad. Sí, esa conexión donde te ha costado una fortuna el renovar tu red y donde hay que diseñar nuevos servicios para darle valor. ¿Quién quiere una fibra para navegar por internet si con 10Mbps lo haces de sobra desde el móvil?
Como ves, un sistema de cloud gaming ofrece unas ventajas interesantes tanto al usuario como al generador de contenido, que hace uso y da sentido a las nuevas infraestructuras de alta capacidad que se están desplegado actualmente por medio mundo.
2015/11/11
2015/06/23
Windows 10 build 10130 comes with a serious bug when trying to access to a remote samba share (this doesn't happen with native Windows 2012 or later).
If you cannot access your home NAS fix is easy: Remove PIN authentication (recommended by Microsoft) and use classic user and password way.
That's all, friends.
Windows 10 build 10130 presenta un bug bastante serio (y coñazo) cuando intentas acceder a una compartición samba remota (carpeta de Windows). Este problema no sucede accediendo a Windows 2012 o posterior.
Si no puedes acceder a la NAS de tu casa la solución es sencilla: elimina la autentificación por PIN (que Microsoft recomienda) y utiliza el sistema clásico de usuario y contraseña.
Así de fácil.
If you cannot access your home NAS fix is easy: Remove PIN authentication (recommended by Microsoft) and use classic user and password way.
That's all, friends.
Windows 10 build 10130 presenta un bug bastante serio (y coñazo) cuando intentas acceder a una compartición samba remota (carpeta de Windows). Este problema no sucede accediendo a Windows 2012 o posterior.
Si no puedes acceder a la NAS de tu casa la solución es sencilla: elimina la autentificación por PIN (que Microsoft recomienda) y utiliza el sistema clásico de usuario y contraseña.
Así de fácil.
Windows 10 en camino.
Casi todos los que me conocéis sabéis lo poco amigo del software propietario que soy, y en particular lo poco que nunca me ha gustado Windows.
Después de aquella versión muy buena de Windows 2000, vino XP (para muchos la mejor, para mí un puro lavado de cara a Windows 2000), la nefasta Windows Vista, la decente Windows 7, el cagarro de Windows 8 y 8.1 (ojo, a nivel de estabilidad nada que reprochar, pero se olvidaron de los sobremesa por el camino), y ahora Windows 10.
Llevo unos días trasteando con la TP, y en general mis impresiones son muy gratas. La interfaz es una vuelta en ordenadores de sobremesa a Windows 7, pero mucho más limpia y con una estética mucho más moderna. Hereda las buenas sensaciones en cuanto a rendimiento de Windows 8. Y para ser una TP en general es estable, bastante estable, incluso el Proyecto Spartan que aun lo veo un poco "pobre" en cuanto a configuraciones pero al menos rápido. En fin, que creo que Microsoft apunta por buen camino.
A ver si de cara a la release final se aclaran con el tema del licenciamiento y de una vez adoptan el modelo Apple de no cobrar por el sistema operativo y sí por los servicios sobre el mismo. Sería un punto a su favor y un claro guiño de Nadella hacia el futuro.
Después de aquella versión muy buena de Windows 2000, vino XP (para muchos la mejor, para mí un puro lavado de cara a Windows 2000), la nefasta Windows Vista, la decente Windows 7, el cagarro de Windows 8 y 8.1 (ojo, a nivel de estabilidad nada que reprochar, pero se olvidaron de los sobremesa por el camino), y ahora Windows 10.
Llevo unos días trasteando con la TP, y en general mis impresiones son muy gratas. La interfaz es una vuelta en ordenadores de sobremesa a Windows 7, pero mucho más limpia y con una estética mucho más moderna. Hereda las buenas sensaciones en cuanto a rendimiento de Windows 8. Y para ser una TP en general es estable, bastante estable, incluso el Proyecto Spartan que aun lo veo un poco "pobre" en cuanto a configuraciones pero al menos rápido. En fin, que creo que Microsoft apunta por buen camino.
A ver si de cara a la release final se aclaran con el tema del licenciamiento y de una vez adoptan el modelo Apple de no cobrar por el sistema operativo y sí por los servicios sobre el mismo. Sería un punto a su favor y un claro guiño de Nadella hacia el futuro.
2015/06/21
Configurar router ASUS ac66u (o ac68u) con Movistar FTTH + Movistar TV + multipantalla
Buenas.
** IMPORTANTE: ASUS está añadiendo esta funcionalidad de serie en sus routers con el perfil Movistar Triple VLAN (no Movistar a secas). No está aun implementado en todos los routers, pero imagino lo estará a no mucho tardar. Antes de empezar con el tutorial, te recomiendo descargues y pruebes con el último firmware de ASUS oficial. En el caso del rt-ac66u, por poner un caso, ya lo incorpora. El perfil se selecciona desde LAN -> IPTV.
Si por el contrario no lo soporta o prefieres usar el firmware de Rmerlin que incluye mejoras sobre el original de ASUS, continua con el tutorial.
Tras un viernes por la noche iluminado, finalmente conseguí configurar mi router ASUS RT-ac66u para sustituir completamente a "la cosa grande y negra" (como dice mi amigo Juan Luis), manteniendo la configuración de Movistar TV y sin necesidad de tocar el desco con IP fija ni mandangas similares.
Esto, además, permite tener multicliente de Movistar TV (varios descos, Raspberry Pi, VLC, etc), lo cual en todos los tutoriales que he visto hasta la fecha es imposible (me refiero a tutoriales para el Asus con firmware AsusWRT o derivados).
Requisitos:
* Router ASUS RT-AC66U (posiblemente este método es válido para otros modelos de Asus modernos, en particular el RT-AC68U, RT-N66U, RT-AC56U, RT-AC68U, RT-AC68P, RT-AC87, RT-AC3200.
* Firmware alternativo de RMerlin AsusWRT. Este firmare es sustituto del oficial de Asus pero mantiene prácticamente al 100% su funcionalidad o la expande, con la misma interfaz. Está basado precisamente en el firmware oficial de Asus pero con mejoras y se instala simplemente como una actualización del mismo. Volver de este firmware al oficial de Asus es trivial, y basta simplemente con actualizar desde la pantalla de administración al firmware de Asus nuevamente. Es estable, MUY ESTABLE, y tan sencillo de usar como el original, pero incluye mejoras en rendimiento y algunas modificaciones necesarias para poder configurar Movistar TV vía NAT.
* IP, máscara de red y gateway de la conexión de Movistar TV. La podéis obtener del desco original siguiente los otros tutoriales al respecto. Os recomiendo la aplicación de Noltari para a partir del backup de la configuración de vuestro router actual, os indique dicha IP.
A partir de aquí, el mecanismo es él siguiente:
1- Debemos configurar nuestro router en modalidad PPPoE para la conexión a internet en el menu WAN (adjunto pantallazo). No os preocupéis en exceso por el username y password. En realidad podéis poner lo que queráis porque hace ya muchos años que Movistar pasa de hacer uso del radius para la Auth, así como si queréis poner vuestro correo electrónico, os valdrá. OJO A LOS DNS: Tenéis que usar los de Movistar. Si usáis los de Google o cualquier otro, algún servicio puede que no os funcione.
2- Ahora accederemos a LAN - IPTV y configuraremos la VLAN de acceso a internet (VLAN6). No cedáis a la tentación de seleccionar Movistar TV como proveedor porque en ese caso perderéis el puerto 3 y 4 del switch y está pensado para funcionar como bridge, meter ahí el desco y no podréis tener la televisión en el resto de los aparatos de vuestra red, que es precisamente lo que buscamos. Dejad el proxy IGMP como "disabled" para evitar que arranque con la configuración por defecto de ASUS.
3- Finalmente, configuraremos la particion JFFS. Esta es una funcionalidad que no trae el firmware original de Asus y que sirve para ejecutar algunos scripts y comandos tras arrancar el router. Aquí es donde está la "magia" de todo esto y lo que más tiempo me llevó. Se accede desde el menú Administration - System. La primera vez que lo configuréis, debéis marcar la opción de Formatear partición en el siguiente reinicio. Esto solo la primera vez. Luego pasará estar desmarcado y no lo volveremos a tocar. Además deberéis activar el acceso SSH para poder acceder por consola al router.
Con esto tendremos ya el router ASUS sustituyendo a la "cosa grande y negra", y directamente conectado a la ONT de Movistar. Ahora viene la parte divertida y la que tiene ya algo de complicación. Necesitarás un cliente SSH (putty, MobaXterm o similar en Windows) o simplemente el ssh de siempre si accedes desde Linux o MAC. 4- Accedemos via SSH a nuestro router con el usuario y contraseña que hayamos definido al configurarlo. 5- Entramos en la carpeta /jffs/scripts y creamos un primer fichero llamado services-start con el siguiente contenido (para los no versados en Unix, los comandos a continuación)
Ojo: Ajustad este script comentando la línea del AC66u y descomentando la correspondiente a vuestro router (AC56u, AC67u o AC68u). Las he añadido en base a las aportaciones de los comentarios de diferentes compañeros y sus experiencias.
Repetiremos los mismos pasos con dos scripts más: firewall-start y nat-start. Los contenidos han de ser los siguientes:
Para firewall-start:
Para nat-start:
Una vez creados los tres scripts, deberemos hacerlos ejecutables. Para ello:
Ahora iremos a la carpeta de configuraciones para configurar el igmpproxy, que es el daemon que nos permite retransmitir multicast a nuestra red.
Puslamos ESC i (escape y luego i) para empezar a meter contenido, e insertamos las siguientes líneas TAL CUAL.
Pruebas:
Haced ping 172.26.23.3 desde el router. Debe responder. Esto implica que services-start está funcionando.
Haced ping 172.26.23.3 desde un ordenador de la red. Debe responder. Esto implica que firewall-start y nat-start están funcionando.
Nota: desde hace un tiempo, 172.26.23.3 ya no responde a ping. Recomiendo hacer en su lugar un traceroute. Si hay respuesta desde cualquier 10.X.X.X, está enrutando correctamente.
Windows: tracert -d 172.26.23.3
Linux: traceroute -In 172.26.23.3
Conectar desco de Movistar TV. Debe funcionar. Si no funciona, el proxy IGMP no está funcionando.
NOTA: En caso de actualizar el firmware del router, estos scripts se borrarán, por lo que habrá que volver a añadirlos. No siempre es asi, pero tenedlo en cuenta.
NOTA2: Si tenéis activo en el control parental del router el filtrado por DNS, no os funcionarán las funciones avanzadas del desco (grabar, etc), porque los DNSs de los filtros no tienen esas URLs disponibles. Añadid una excepción para que el router de Movistar TV no tenga filtro parental.
** IMPORTANTE: ASUS está añadiendo esta funcionalidad de serie en sus routers con el perfil Movistar Triple VLAN (no Movistar a secas). No está aun implementado en todos los routers, pero imagino lo estará a no mucho tardar. Antes de empezar con el tutorial, te recomiendo descargues y pruebes con el último firmware de ASUS oficial. En el caso del rt-ac66u, por poner un caso, ya lo incorpora. El perfil se selecciona desde LAN -> IPTV.
Si por el contrario no lo soporta o prefieres usar el firmware de Rmerlin que incluye mejoras sobre el original de ASUS, continua con el tutorial.
Tras un viernes por la noche iluminado, finalmente conseguí configurar mi router ASUS RT-ac66u para sustituir completamente a "la cosa grande y negra" (como dice mi amigo Juan Luis), manteniendo la configuración de Movistar TV y sin necesidad de tocar el desco con IP fija ni mandangas similares.
Esto, además, permite tener multicliente de Movistar TV (varios descos, Raspberry Pi, VLC, etc), lo cual en todos los tutoriales que he visto hasta la fecha es imposible (me refiero a tutoriales para el Asus con firmware AsusWRT o derivados).
Requisitos:
* Router ASUS RT-AC66U (posiblemente este método es válido para otros modelos de Asus modernos, en particular el RT-AC68U, RT-N66U, RT-AC56U, RT-AC68U, RT-AC68P, RT-AC87, RT-AC3200.
* Firmware alternativo de RMerlin AsusWRT. Este firmare es sustituto del oficial de Asus pero mantiene prácticamente al 100% su funcionalidad o la expande, con la misma interfaz. Está basado precisamente en el firmware oficial de Asus pero con mejoras y se instala simplemente como una actualización del mismo. Volver de este firmware al oficial de Asus es trivial, y basta simplemente con actualizar desde la pantalla de administración al firmware de Asus nuevamente. Es estable, MUY ESTABLE, y tan sencillo de usar como el original, pero incluye mejoras en rendimiento y algunas modificaciones necesarias para poder configurar Movistar TV vía NAT.
* IP, máscara de red y gateway de la conexión de Movistar TV. La podéis obtener del desco original siguiente los otros tutoriales al respecto. Os recomiendo la aplicación de Noltari para a partir del backup de la configuración de vuestro router actual, os indique dicha IP.
A partir de aquí, el mecanismo es él siguiente:
1- Debemos configurar nuestro router en modalidad PPPoE para la conexión a internet en el menu WAN (adjunto pantallazo). No os preocupéis en exceso por el username y password. En realidad podéis poner lo que queráis porque hace ya muchos años que Movistar pasa de hacer uso del radius para la Auth, así como si queréis poner vuestro correo electrónico, os valdrá. OJO A LOS DNS: Tenéis que usar los de Movistar. Si usáis los de Google o cualquier otro, algún servicio puede que no os funcione.
2- Ahora accederemos a LAN - IPTV y configuraremos la VLAN de acceso a internet (VLAN6). No cedáis a la tentación de seleccionar Movistar TV como proveedor porque en ese caso perderéis el puerto 3 y 4 del switch y está pensado para funcionar como bridge, meter ahí el desco y no podréis tener la televisión en el resto de los aparatos de vuestra red, que es precisamente lo que buscamos. Dejad el proxy IGMP como "disabled" para evitar que arranque con la configuración por defecto de ASUS.
3- Finalmente, configuraremos la particion JFFS. Esta es una funcionalidad que no trae el firmware original de Asus y que sirve para ejecutar algunos scripts y comandos tras arrancar el router. Aquí es donde está la "magia" de todo esto y lo que más tiempo me llevó. Se accede desde el menú Administration - System. La primera vez que lo configuréis, debéis marcar la opción de Formatear partición en el siguiente reinicio. Esto solo la primera vez. Luego pasará estar desmarcado y no lo volveremos a tocar. Además deberéis activar el acceso SSH para poder acceder por consola al router.
Con esto tendremos ya el router ASUS sustituyendo a la "cosa grande y negra", y directamente conectado a la ONT de Movistar. Ahora viene la parte divertida y la que tiene ya algo de complicación. Necesitarás un cliente SSH (putty, MobaXterm o similar en Windows) o simplemente el ssh de siempre si accedes desde Linux o MAC. 4- Accedemos via SSH a nuestro router con el usuario y contraseña que hayamos definido al configurarlo. 5- Entramos en la carpeta /jffs/scripts y creamos un primer fichero llamado services-start con el siguiente contenido (para los no versados en Unix, los comandos a continuación)
cd /jffs/scriptsPuslamos ESC i (escape y luego i) para empezar a meter contenido, e insertamos las siguientes líneas TAL CUAL. Debéis sustituir la IP de Movistar TV, Máscara y Gateway por aquellas que hayáis conseguido de la web de Noltari.
vi services-start
Ojo: Ajustad este script comentando la línea del AC66u y descomentando la correspondiente a vuestro router (AC56u, AC67u o AC68u). Las he añadido en base a las aportaciones de los comentarios de diferentes compañeros y sus experiencias.
#!/bin/shPara guardar los cambios, pulsaremos consecutivalente ESC, :wq y finalmente INTRO (escape, dos pultos, w, q, e INTRO en dicho orden). Volveremos a la pantalla inicial de consola.
MOVISTAR_TV_IP=10.64.XX.XX
MOVISTAR_TV_MASK=255.192.0.0
MOVISTAR_TV_GW=10.64.0.1
# Configuramos switch para Movistar TV (VLAN2 tagged en WAN y router interno para el AC66U. En otros modelo cambiar por la correspondiente)
robocfg vlan 2 ports "0t 8t"
# AC66u: robocfg vlan 2 ports "0t 8t"
# AC68u: robocfg vlan 2 ports "0t 5t"
# AC67u: robocfg vlan 2 ports "0t 7t"
# AC56u: robocfg vlan 2 ports "4t 5t"
# Añadimos VLAN2 en puerto WAN
vconfig add eth0 2
# Asigamos IP a VLAN del router
ifconfig vlan2 $MOVISTAR_TV_IP netmask $MOVISTAR_TV_MASK up
# Añadimos rutas Movistar TV
ip route add to 172.26.0.0/16 via $MOVISTAR_TV_GW
ip route add to 172.23.0.0/16 via $MOVISTAR_TV_GW
sleep 30
/usr/sbin/igmpproxy /jffs/configs/igmpproxy.conf
Repetiremos los mismos pasos con dos scripts más: firewall-start y nat-start. Los contenidos han de ser los siguientes:
Para firewall-start:
#!/bin/sh
# Habilitamos firewall
iptables -I INPUT -p igmp -i vlan2 -d 224.0.0.0/4 -j ACCEPT
iptables -I INPUT -p udp -m udp -i vlan2 -d 224.0.0.0/4 -j ACCEPT
iptables -I FORWARD -p igmp -i vlan2 -d 224.0.0.0/4 -j ACCEPT
iptables -I FORWARD -p udp -i vlan2 -m udp -d 224.0.0.0/4 -j ACCEPT
iptables -I FORWARD -o vlan2 -j ACCEPT
#Deshabilitamos filtro de IGMP en vlan2
/bin/echo 0 > /proc/sys/net/ipv4/conf/vlan2/rp_filter
/bin/echo 0 > /proc/sys/net/ipv4/conf/br0/rp_filter
Para nat-start:
#!/bin/sh
# Habilitamos NAT en firewall
iptables -t nat -I POSTROUTING -o vlan2 -j MASQUERADE
#Deshabilitamos filtro de IGMP en vlan2
/bin/echo 0 > /proc/sys/net/ipv4/conf/vlan2/rp_filter
/bin/echo 0 > /proc/sys/net/ipv4/conf/br0/rp_filter
cd /jffs/scripts
chmod a+x *
Ahora iremos a la carpeta de configuraciones para configurar el igmpproxy, que es el daemon que nos permite retransmitir multicast a nuestra red.
cd /jffs/configs
vi igmpproxy.conf
Puslamos ESC i (escape y luego i) para empezar a meter contenido, e insertamos las siguientes líneas TAL CUAL.
quickleave
phyint vlan2 upstream ratelimit 0 threshold 1
altnet 172.26.0.0/16;
altnet 172.23.0.0/16;
phyint br0 downstream ratelimit 0 threshold 1
Para guardar los cambios, pulsaremos consecutivamente ESC, :wq y finalmente INTRO (escape, dos pultos, w, q, e INTRO en dicho orden). Volveremos a la pantalla inicial de consola.
Con esto ya tendremos completamente configurado el router para funcionar con Movistar TV desde cualquier dispositivo de nuestra red interna. Esta configuración se aplicará automáticamente siempre que se reinicie el router, pero podemos probarla antes ejecutando manualmente los tres scripts.
cd /jffs/scripts
./services-start
./firewall-start
./nat-start
Haced ping 172.26.23.3 desde el router. Debe responder. Esto implica que services-start está funcionando.
Haced ping 172.26.23.3 desde un ordenador de la red. Debe responder. Esto implica que firewall-start y nat-start están funcionando.
Nota: desde hace un tiempo, 172.26.23.3 ya no responde a ping. Recomiendo hacer en su lugar un traceroute. Si hay respuesta desde cualquier 10.X.X.X, está enrutando correctamente.
Windows: tracert -d 172.26.23.3
Linux: traceroute -In 172.26.23.3
Conectar desco de Movistar TV. Debe funcionar. Si no funciona, el proxy IGMP no está funcionando.
NOTA: En caso de actualizar el firmware del router, estos scripts se borrarán, por lo que habrá que volver a añadirlos. No siempre es asi, pero tenedlo en cuenta.
NOTA2: Si tenéis activo en el control parental del router el filtrado por DNS, no os funcionarán las funciones avanzadas del desco (grabar, etc), porque los DNSs de los filtros no tienen esas URLs disponibles. Añadid una excepción para que el router de Movistar TV no tenga filtro parental.
Tras... ¿CINCO AÑOS?? Cielos, ¡cómo pasa el tiempo!, vuelvo a añadir alguna entrada a mi abandonado blog. La verdad es que tampoco es que pueda decir que ahora tenga más tiempo en le pasado. Nada más lejos de la realidad. Y por supuesto en este tiempo han sucedido muchas cosas que han apartado mi atención de estos temas tan mundanos y me han obligado a centrarme más en el día a día...
Desde el punto de vista laboral, tal vez lo más relevante es que a finales de 2014, y muy a mi pesar, abandoné "mi empresa de toda la vida", VectorSF (ahora Vector ITC group o como quiera que lo llamen) para comenzar un proyecto totalmente nuevo y apasionante. Nada que ver con lo que hasta ahora había hecho. Vuelta a los orígenes, a una startup, a diseñar, investigar, pensar, imaginar... Hacía muchos años que no me metía tan de lleno en un día a día tan alejado de las tareas, en muchos casos rutinarias y aburridas(informes de seguimiento, presupuestos, reuniones, planes, certificaciones de calidad, politiqueos, cuchilladas traperas, etc) con las que tuve que lidiar estos últimos años.
¿Y que decir sobre PlayGiga? Pues que estamos construyendo DESDE CERO una plataforma de Cloud Gaming, o streaming de juegos desde la nube. Básicamente, para los no versados, consiste en ejecutar los actuals juegos de PC en un sistema remote (servidores muy potentes) y, en tiempo real, comprimir la imágen y enviarla hasta un visualizador que puede ser un PC, un tablet, un smartphone...un STB Android, el desco de ver la TV de tu casa... para que desde este ultimo se pueda tomar control del mismo y jugar en remote sin necesidad de tener un equipo potente ni instalar juegos, ni tener que ir a la tienda a comprar un DVD ni descargar desde Steam el programa de turno. Así, en corto. Pero sobre esto hay muuuucho que escribir que me podría llevar entradas y más entradas, además de violar mi NDA. :-)
2010/10/18
Zimbra 6.X. La actualizción más sencilla.
Este fin de semana finalmente me animé a actualizar a Zimbra 6.x
A pesar de que esta release llevaba meses en el mercado, y e igualmente a pesar de que soy un gran forofo de Zimbra y siempre suelo estar a la última o a lo sumo una o dos "minor releases" por detrás, esta vez me lo tomé con mucha más calma.
Por un lado, la migración a Zimbra 6.0 desde 5.5 nos dio muchos problemas en el entorno de laboratorio cuando salió la 6.0.1, lo cual nos hizo replantearnos un upgrade tempranero.
Por otro lado el paso a 6.0 iba con la sutil sugerencia por parte de Zimbra de que la 6.0 será la última versión soportada sobre Red Hat 4.x, sistema operativo que utilizamos para nuestro sistema de correo desde que empezamos con la versión 3.5 de Zimbra.
Así pues, mi idea original pasaba por hacer un upgrade "in-place" a Red Hat 5.X para posteriormente retomar la actualización de Zimbra. No obstante, un upgrade del sistema operativo implica un reinicio total de la máquina, el uso de DVDs (ciertamente, RedHat en este aspecto hace años que debería haberse puesto las pilas) y a fin de cuentas presencia física en la oficina, en horarios intempestivos, y sin realmente hacer mucho (solo mirar y cruzar los dedos).
Posteriormente opté por que tal vez fuera mejor opción aprovechar todo de una vez, pasar a una distro seria para el tema de actualizaciones (Ubuntu 10.04 LTS es la precandidata en este caso) y de paso acometer esa virtualización que llevo meses planeando. Lamentablemente este proceso lleva igualmente mucho tiempo, dado que el manual "oficioso" de zimbra implica un full backup & restore, el cual lleva casi 12 horas... too much time...
Así que finalmente me he decantado por un upgrade de zimbra "a la exchange", esto es, montando un segundo servidor en un pool y finalmente moviendo los buzones del servidor antiguo al nuevo.
Pero para ello, ambos servidores de zimbra han de ir al mismo nivel de revisión. Y dado que es absurdo instalar una 5.0.23 para luego actualizar a 6.0.8, últimas versiones disponibles a día de hoy para la 5.x y 6.x, opté por actualizar primero la instalación existente, montar posteriormente nuestro nuevo servidor, y migrar cuando haya tiempo y ganas de pasar un poco de tensión.
He de reconocer que la actualización desde la 5.0.23 a la 6.0.8 ha sido fabulosa. Si con las pruebas entre la 5.0.18 y la 6.0.1 las pasamos canutas, en esta ocasión no hubo problema alguno. Ni en el entorno de laboratorio ni en el entorno real.
La operación duró 30 minutos, durante los cuales tuve tiempo para portar los cambios menores que hacemos a Zimbra para adaptarlo a nuestras necesidades que son básicamente un skin propio con logos de la compañía, cambiar el corrector ortográfico al español, y ajustes al sistema anti-spam.
Una vez terminado el upgrade, el sistema se ha levantado a la primera sin un solo fallo. Se le nota más ligero, dado que he aprovechado para activar memcached y darle un poco de vidilla a la base de datos. Además el paso a Java 1.6.0 también se ha notado bastante.
Entre las novedades que son muchas pero no destacan por ser especialmente espectaculares, sobresale la adición de acuses de recibo desde la interfaz web, la nueva gestión de ACLs para administración delegada del servidor, un puñetero bug para la sincronización de Zimbra Mobile en dispositivos Android que hacía que no se pudieran enviar correos con el cliente nativo de HTC, un nuevo sistema de estadísticas mucho más ligero (lamentablemente perdemos tres años de estadísticas con el cambio), mejoras en la interfaz web (estándar, extendida y móvil), mejoras en el conector de Outlook para gestión de permisos, y muchos, muchos bugs solucionados.
Se echa en falta mi eterna petición de "firma corporativa" o "disclaimer corporativo", lo cual odio pero es motivo de queja constante por parte de algún departamento de la empresa.
Ah, la migración del sistema operativo a Ubuntu LTS 10.04 para más adelante, dado que el soporte para 10.04 LTS por parte de Zimbra todavía está en beta. ;)
A pesar de que esta release llevaba meses en el mercado, y e igualmente a pesar de que soy un gran forofo de Zimbra y siempre suelo estar a la última o a lo sumo una o dos "minor releases" por detrás, esta vez me lo tomé con mucha más calma.
Por un lado, la migración a Zimbra 6.0 desde 5.5 nos dio muchos problemas en el entorno de laboratorio cuando salió la 6.0.1, lo cual nos hizo replantearnos un upgrade tempranero.
Por otro lado el paso a 6.0 iba con la sutil sugerencia por parte de Zimbra de que la 6.0 será la última versión soportada sobre Red Hat 4.x, sistema operativo que utilizamos para nuestro sistema de correo desde que empezamos con la versión 3.5 de Zimbra.
Así pues, mi idea original pasaba por hacer un upgrade "in-place" a Red Hat 5.X para posteriormente retomar la actualización de Zimbra. No obstante, un upgrade del sistema operativo implica un reinicio total de la máquina, el uso de DVDs (ciertamente, RedHat en este aspecto hace años que debería haberse puesto las pilas) y a fin de cuentas presencia física en la oficina, en horarios intempestivos, y sin realmente hacer mucho (solo mirar y cruzar los dedos).
Posteriormente opté por que tal vez fuera mejor opción aprovechar todo de una vez, pasar a una distro seria para el tema de actualizaciones (Ubuntu 10.04 LTS es la precandidata en este caso) y de paso acometer esa virtualización que llevo meses planeando. Lamentablemente este proceso lleva igualmente mucho tiempo, dado que el manual "oficioso" de zimbra implica un full backup & restore, el cual lleva casi 12 horas... too much time...
Así que finalmente me he decantado por un upgrade de zimbra "a la exchange", esto es, montando un segundo servidor en un pool y finalmente moviendo los buzones del servidor antiguo al nuevo.
Pero para ello, ambos servidores de zimbra han de ir al mismo nivel de revisión. Y dado que es absurdo instalar una 5.0.23 para luego actualizar a 6.0.8, últimas versiones disponibles a día de hoy para la 5.x y 6.x, opté por actualizar primero la instalación existente, montar posteriormente nuestro nuevo servidor, y migrar cuando haya tiempo y ganas de pasar un poco de tensión.
He de reconocer que la actualización desde la 5.0.23 a la 6.0.8 ha sido fabulosa. Si con las pruebas entre la 5.0.18 y la 6.0.1 las pasamos canutas, en esta ocasión no hubo problema alguno. Ni en el entorno de laboratorio ni en el entorno real.
La operación duró 30 minutos, durante los cuales tuve tiempo para portar los cambios menores que hacemos a Zimbra para adaptarlo a nuestras necesidades que son básicamente un skin propio con logos de la compañía, cambiar el corrector ortográfico al español, y ajustes al sistema anti-spam.
Una vez terminado el upgrade, el sistema se ha levantado a la primera sin un solo fallo. Se le nota más ligero, dado que he aprovechado para activar memcached y darle un poco de vidilla a la base de datos. Además el paso a Java 1.6.0 también se ha notado bastante.
Entre las novedades que son muchas pero no destacan por ser especialmente espectaculares, sobresale la adición de acuses de recibo desde la interfaz web, la nueva gestión de ACLs para administración delegada del servidor, un puñetero bug para la sincronización de Zimbra Mobile en dispositivos Android que hacía que no se pudieran enviar correos con el cliente nativo de HTC, un nuevo sistema de estadísticas mucho más ligero (lamentablemente perdemos tres años de estadísticas con el cambio), mejoras en la interfaz web (estándar, extendida y móvil), mejoras en el conector de Outlook para gestión de permisos, y muchos, muchos bugs solucionados.
Se echa en falta mi eterna petición de "firma corporativa" o "disclaimer corporativo", lo cual odio pero es motivo de queja constante por parte de algún departamento de la empresa.
Ah, la migración del sistema operativo a Ubuntu LTS 10.04 para más adelante, dado que el soporte para 10.04 LTS por parte de Zimbra todavía está en beta. ;)
Una larga temporada apagado pero seguimos mejorando.
En los últimos meses apenas he escrito entradas en el blog. Y es que ciertamente cuando uno es padre por segunda vez le queda poco tiempo libre que dedicar a este tipo de historias. Obviamente, en el trabajo hemos seguido adelante con mogollón de proyectos interesantes que podrían haber dado para escribir varias entradas. Pero como tampoco ahora mismo tengo tiempo, me limitaré a enumerar las cosas más importantes durante todo este tiempo:
- Proyecto de virtualización: Hemos acometido un importante proyecto de virtualización de todo el entorno de producción. En el mes de Marzo pusimos a funcionar un entorno Vmware vSphere 4 sobre micros Intel Xeon 55XX (Nehalem) que nos ha facilitado y mucho la vida.
El sistema se compone de dos servidores Dell Poweredege R610 con 32GB de memoria RAM, dos micros quad core cada uno, y una cabina Dell Equalogic PS4000 con unos 4TB de espacio de almacenamiento en RAID10. Para completar, un Dell Poweredge R410 con vmware vCenter como sistema de control centralizado.
Durante este tiempo se han ido consolidando en este entorno los diferentes servidores de producción: herramientas de gestión de proyectos (gForge), gestión de facturación, contabilidad, intranet, servidor de VoIP (de backup), controlador de dominio SAMBA/CIFS, parte de la web pública, Team Foundation Server, proxies reversos, servidor de Bussiness Inteligence (Pentaho) y multitud de servicios accesorios que se repartían por un elenco de servidores.
A día de hoy únicamente nos queda por virtualizar el servidor de correo electrónico (Zimbra) y el servidor de gestor documental (Xerox Docushare) los cuales han sido pospuestos por los requerimientos de espacio que implican que una conversión "physical to virtual" llevaría demasiado tiempo. En algún momento se abordará.
El sistema ha sido recientemente actualizado a vSphere 4.1, que entre otras mejoras aporta memoria comprimida en las distintas máquinas virtuales, lo cual redunda en una óptima gestión de los recursos. En nuestro caso el uso de CPU no es el problema, así que el sistema no ha notado merma alguna en cuanto a rendimiento.
En lo referente precisamente a este último aspecto, la respuesta a la pregunta que muchos se hacen es NO, NO HEMOS NOTADO MERMA ALGUNA EN EL RENDIMIENTO AL VIRTUALIZAR. Es más, el rendimiento es muy superior a lo existente, por cuanto que el sistema de almacenamiento en SAN y la potencia de las máquinas físicas que componen el entorno es muy superior al hardware que reemplaza.
- Nuevo sistema de VPNs. Hemos mejorado el sistema de VPNs reemplazando un viejo Cisco VPN Concentrator 3000 por un flamante Cisco ASA5510. Los problemas recurrentes con la estabilidad de las conexiones IPSec nos forzaron a reemplazar el equipo original.
- Actualización a Zimbra 6.
- Incremento de la capacidad de nuestras líneas de comunicaciones con los diferentes centros y creación de VPNs especializadas con diferenciación por servicio (VPN, red interna, red de cliente).
- Proyecto de virtualización: Hemos acometido un importante proyecto de virtualización de todo el entorno de producción. En el mes de Marzo pusimos a funcionar un entorno Vmware vSphere 4 sobre micros Intel Xeon 55XX (Nehalem) que nos ha facilitado y mucho la vida.
El sistema se compone de dos servidores Dell Poweredege R610 con 32GB de memoria RAM, dos micros quad core cada uno, y una cabina Dell Equalogic PS4000 con unos 4TB de espacio de almacenamiento en RAID10. Para completar, un Dell Poweredge R410 con vmware vCenter como sistema de control centralizado.
Durante este tiempo se han ido consolidando en este entorno los diferentes servidores de producción: herramientas de gestión de proyectos (gForge), gestión de facturación, contabilidad, intranet, servidor de VoIP (de backup), controlador de dominio SAMBA/CIFS, parte de la web pública, Team Foundation Server, proxies reversos, servidor de Bussiness Inteligence (Pentaho) y multitud de servicios accesorios que se repartían por un elenco de servidores.
A día de hoy únicamente nos queda por virtualizar el servidor de correo electrónico (Zimbra) y el servidor de gestor documental (Xerox Docushare) los cuales han sido pospuestos por los requerimientos de espacio que implican que una conversión "physical to virtual" llevaría demasiado tiempo. En algún momento se abordará.
El sistema ha sido recientemente actualizado a vSphere 4.1, que entre otras mejoras aporta memoria comprimida en las distintas máquinas virtuales, lo cual redunda en una óptima gestión de los recursos. En nuestro caso el uso de CPU no es el problema, así que el sistema no ha notado merma alguna en cuanto a rendimiento.
En lo referente precisamente a este último aspecto, la respuesta a la pregunta que muchos se hacen es NO, NO HEMOS NOTADO MERMA ALGUNA EN EL RENDIMIENTO AL VIRTUALIZAR. Es más, el rendimiento es muy superior a lo existente, por cuanto que el sistema de almacenamiento en SAN y la potencia de las máquinas físicas que componen el entorno es muy superior al hardware que reemplaza.
- Nuevo sistema de VPNs. Hemos mejorado el sistema de VPNs reemplazando un viejo Cisco VPN Concentrator 3000 por un flamante Cisco ASA5510. Los problemas recurrentes con la estabilidad de las conexiones IPSec nos forzaron a reemplazar el equipo original.
- Actualización a Zimbra 6.
- Incremento de la capacidad de nuestras líneas de comunicaciones con los diferentes centros y creación de VPNs especializadas con diferenciación por servicio (VPN, red interna, red de cliente).
2010/01/12
Red y Libertad
Los internautas consideramos imprescindible la retirada de la disposición final primera de la Ley de Economía Sostenible por los siguientes motivos:
1) Viola los derechos constitucionales en los que se ha de basar un estado democrático en especial la presunción de inocencia, libertad de expresión, privacidad, inviolabilidad domiciliaria, tutela judicial efectiva, libertad de mercado, protección de consumidoras y consumidores, entre otros.
2) Genera para la Internet un estado de excepción en el cual la ciudadanía será tratada mediante procedimientos administrativos sumarísimos reservados por la Audiencia Nacional a narcotraficantes y terroristas.
3) Establece un procedimiento punitivo “a la carta” para casos en los que los tribunales ya han manifestado que no constituían delito, implicando incluso la necesidad de modificar al menos 4 leyes, una de ellas orgánica. Esto conlleva un cambio radical en el sistema jurídico y una fuente de inseguridad para el sector de las TIC (Tecnología de la Información y la Comunicación). Recordamos, en este sentido, que el intercambio de conocimiento y cultura en la red es un motor económico importante para salir de la crisis como se ha demostrado ampliamente.
4) Los mecanismos preventivos urgentes de los que dispone la ley y la judicatura son para proteger a toda ciudadanía frente a riesgos tan graves como los que afectan a la salud pública. El gobierno pretende utilizar estos mismos mecanismos de protección global para beneficiar intereses particulares frente a la ciudadanía. Además la normativa introducirá el concepto de “lucro indirecto”, es decir: a mí me pueden cerrar el blog porque “promociono” a uno que “promociona” a otro que vincula a un tercero que hace negocios presuntamente ilícitos.
5) Recordamos que la propiedad intelectual no es un derecho fundamental contrariamente a las declaraciones del Ministro de Justicia, Francisco Caamaño. Lo que es un derecho fundamental es el derecho a la producción literaria y artística.
6) De acuerdo con las declaraciones de la Ministra de Cultura, esta disposición se utilizará exclusivamente para cerrar 200 webs que presuntamente están atentando contra los derechos de autor. Entendemos que si éste es el objetivo de la disposición, no es necesaria, ya que con la legislación actual existen procedimientos que permiten actuar contra webs, incluso con medidas cautelares, cuando presuntamente se esté incumpliendo la legalidad. Por lo que no queda sino recelar de las verdaderas intenciones que la motivan ya que lo único que añade a la legislación actual es el hecho de dejar la ciudadanía en una situación de grave indefensión jurídica en el entorno digital.
7) Finalmente consideramos que la propuesta del gobierno no sólo es un despilfarro de recursos sino que será absolutamente ineficaz en sus presuntos propósitos y deja patente la absoluta incapacidad por parte del ejecutivo de entender los tiempos y motores de la Era Digital.
2010/01/02
Papá por segunda vez
Ayer día 1, a las 8:50 de la mañana nació mi segundo peque, Diego, con un peso de 2.750kg y 50 centímetros de "altura".
Es un bichín muy salao con carita de pillo que está todo el día durmiendo y acurrucado con su mami.
A ver si nos sale al menos la mitad de bueno que su hermano mayor, David. ;-D
Es un bichín muy salao con carita de pillo que está todo el día durmiendo y acurrucado con su mami.
A ver si nos sale al menos la mitad de bueno que su hermano mayor, David. ;-D
2009/12/28
Añadir filtro de ADs a Google Chrome / Chromium
Con la llegada de las extensiones, llega igualmente la posibilidad de bloquear ADs de forma sencilla (antes había extensiones "de andar por casa" que no funcionaban demasiado bien).
En principio instalando AdBlock para Google Chrome tendremos ya disponible la extensión, pero habrá que configurarla.
Podemos activar easylist (altamente recomendado)... pero echamos en falta nuestros filtros preferidos que son los de "Filtros Nauscópicos", especializados en webs en habla castellana.
Para añadirlos solo tenemos que hacer lo siguiente.
Editamos el fichero options.html ubicado en nuestro home, dentro de
/.config/chromium/Default/Extensions/gighmmpiobklfepjocnamgkkbiglidom/1.2.22
e inmediatamente de easylist Romanian añadimos lo siguiente:
"easylist_spanish": {
url: "http://s3.amazonaws.com/lcp/maty/myfiles/AdBlock-Nauscopio-maty.txt",
label: " - addittional Spanish filters"
},
... quedando la cosa tal que así...
"easylist_romanian": {
url: "http://www.picpoc.ro/menetzrolist.txt",
label: " - additional Romanian filters"
},
"easylist_spanish": {
url: "http://s3.amazonaws.com/lcp/maty/myfiles/AdBlock-Nauscopio-maty.txt",
label: " - addittional Spanish filters"
},
"adblock_chinalist": {
url:"http://adblock-chinalist.googlecode.com/svn/trunk/adblock.txt",
Por fin extensiones para Google Chrome / Chromium
Finalmente Google ya tiene disponible en su repositorio la tan añorada biblioteca de extensiones que tango echamos de menos los usuarios de Firefox y razón por la cual no nos hemos pasado a usar Google Chrome / Chromium definitivamente (la velocidad es sustancialmente superior a Firefox 3.5).
Es muy sencillo... simplemente hemos de ir al icono de Herramientas / Extensiones y tendremos a nuestra disposición todas las extensiones publicadas hasta la fecha, entre ellas la integración con Gmail, Google Wave, Google Reader, Facebook, ebay, etc, etc... además de mi añorado Adblock.
Punto para Google (otro más).
2009/09/17
Primeras impresiones sobre Android
Esta semana he conseguido de nuestro proveedor habitual un teléfono HTC Hero para poder echarle un vistazo en serio a Android. Este teléfono viene con un Android 1.5, a la espera de Android 2.0 que se espera para finales de año.
¿Impresiones? Pues ciertamente IMPRESIONANTE. Hasta la fecha había hecho uso de smartphones basados en Windows Mobile 5 y 6, y ciertamente la diferencia con respecto a Android es espectacular. Cierto es que los operadores tienden a sobrecargar de aplicaciones absurdas y widgets inútiles sus smartphones, y en el caso de los HTC Diamond, por poner un caso, es realmente terrible. Pero incluso cambiando la ROM por una tuneada (que va mucho mejor que la original), al lado de este HTC Hero con Android palidecen.
Por un lado el rendimiento. No tiene absolutamente nada que ver. La fluidez de la interfaz, la velocidad de respuesta. Es otro mundo. Nada que enviar a los iPhone.
Por otro lado la interfaz. Clara, usable y muy lograda. Y eso que todavía pueden pulirlo más.
En cuanto al elenco de aplicaciones, a pesar de que el marketplace de Android todavía está lejos de la AppStore, las aplicaciones que empiezan a aparecer son muy curiosas. Lectores de código de barras, compresores, terminales de consola, etc, etc. Y todo lo que viene detrás.
Sobre trasteo del teléfono, he aprovechado para cambiarle la RADIO (firmware para GPS, 3G, batería, etc) y actualizar a una ROM más moderna de la propia HTC. Pero realmente el SDK de Android te permite hacer cualquier cosa con el teléfono, pudiendo logarte por consola y trabajar contra el linux que subyace como si de tu propio ordenador se tratara.
En fin, que la experiencia ha sido gratificante y por fin me libro de los ladrillos basados en Windows Mobile. No sé cómo será la versión 6.5... pero Microsoft como siga así lo tiene crudo.
Ah, como no todo puede ser bueno, la aplicación de correo que trae este HTC Hero deja un poco que desear. La parte de sincronización con Exchange funciona muy bien, pero tiene una gran pega y es que no sincroniza automáticamente las carpetas de correo. Esto en mi caso es una gran, GRAN pega. Esperemos que sea corregido pronto (la aplicación no es de Android, si no una aplicación externa proporcionada por la propia HTC).
2009/08/10
Rendimiento en Drupal (II)
Sobre el tema que ocupaba en el anterior post, continuamos.
El site se diseñó sobre Drupal 5.x, el cual aunque tiene importantes mejoras de rendimiento sobre las versiones 4.x, no llega a lo que puede dar de sí 6.x o incluso la 7.x, actualmente en desarrollo.
Es por ello que tuvimos que implementar una serie de mecanismos para reducir el impacto sobre el hardware disponible. Estos fueron los mecanismos implementados.
- Uso intensivo de memcache. Memcache es un sistema de cachés en RAM, como su nombre indica. Se utilizó para evitar queries masivas sobre la base de datos (mysql). Drupal utiliza la base de datos para prácticamente todo. El ir añadiendo módulos y bloques hace que este uso sea tremendamente intensivo. Esto puede llegar a crear un gran problema. Memcache lo que hace es cachear las queries más habituales en una gran tabla hash, lo que reduce a la mínima expresión (updates e inserts) los accesos a BBDD. El impacto de memcache sobre el site fue brutal, especialmente a nivel de BBDD.
- Uso de las cachés internas de Drupal. Drupal 5.x tiene un sistema propio de cachés. Genera un expires en las páginas, de forma que el usuario que navegue no las recargue cada vez que pase por el site. En 5.x este sistema se limita a eso y poco más. En la versión 6.x se cachea por bloque, lo que produce un importante incremento del rendimiento, pero no así en la 5.x. Además, cada vez que un usuario registrado accede, se limpia la caché. Una lástima. Existen algunos módulos interesantes, como "Advanced Cache" (advcache) que mitiga parte del problema, o Block Cache que fue incluído en Drupal 6.x como caché de bloques. En nuestro caso, utilizamos una versión desarrollada a medida y más flexible de block cache para reducir la carga de site, la cual resultó muy beneficiosa.
- Uso de un proxy reverso. En este caso, squid 2.6. Un sistema de caché reversa puede salvar el pescuezo a cualquiera. Al contrario que la caché interna de Drupal que cachea principalmente objetos, el proxy reverso cachea las páginas renderizadas tal cual, así como los gráficos, css, javascript, etc. Si bien estos últimos apenas suponen carga para el servidor web, sí que implican el uso de procesos, escrituras del log, etc, etc. El cacheo de páginas renderizadas libera realmente al site de producción. En nuestro caso, modificamos drupal para generar dos tipos de URL. Una URL genérica para usuarios anónimos, y una URL con un parámetro para usuarios logados, de forma que el sistema de caché reversa cacheara todos los accesos anónimos (segun drupal indicara en su expires) y liberara de los mismos al servidor. Los usuarios logados seguían cargando (y mucho) el site, pero al menos crawlers, usuarios ocasionales (la gran mayoría) ya no lo hacían.
- PHP eaccelerator. Es un acelerador de PHP. Básicamente lo que hace es almacenar el código PHP ya compilado para que el sistema no tenga que volver a interpretarlo cada vez que una página es invocada. El rendimiento del código se incrementa entre x3 y x5. Hay otros sistemas como APC o Xcache que tienen un impacto similar.
- En MySQL, cambio de MyISAM a InnoDB. Soy poco fan de MySQL y siempre me ha parecido que postgres es un sistema de BBDD mucho más robusto, fiable y serio. Pero es lo que hay. Como estábamos trabajando con MySQL 5, teníamos posibilidad de usar InnoDB en lugar de MyISAM como sistema de almacenaniento. Aunque sobre el papel MyISAM es más rápido a la hora de realizar consultas por su mayor simplicidad, InnoDB es mucho más avanzado por cuanto que no bloquea tablas completas en consultas o updates. En nuestro caso, además, prácticamente no usamos las consultas porque memcache las sirve casi todas, y experimentamos bloqueos por queries un tanto "rudas" contra la BBDD que en algunas ocasiones colgaron el sistema. El paso a InnoDB solucionó este problema. Modificamos algunos puntos del código para eliminar bloqueos explícitos que realiza Drupal 5, pensado para MyISAM, en aras de mejorar el rendimiento, aunque como supondréis mucho, poco incrementó dicho rendimiento habida cuenta de que (otra vez) casi todo se lo come memcache.
Adicionalmente a estas medidas, y como red de seguridad, sugerimos una serie de cambios al proveedor (sí, lo sé, esto no debería haber sucedido jamás, pero el mundo de los sysadmins está lleno de manías y no es fácil decirle a uno lo que tiene que hacer. A todos nos sienta mal que nos lo digan).
- Limitar el número de procesos de Apache (para evitar que el servidor se sature). Mejor hacer esperar al usuario unos segundos encolado, a hacerle esperar para siempre porque nuestro servidor se ha ido a freir monas. Aquí lo ideal es realizar un estudio a grosso modo entre la memoria utilizada por proceso, la memoria de la máquina y la potencia de CPU de la máquina. Esto es, si cada proceso viene a tomar 100MB, tenemos una máquina con 2GB de memoria y un procesador doble núcleo, no parece lógico coger más a allá de 15 procesos en Apache para no quedarnos sin memoria... o sin CPU, si la aplicación es muy intensiva.
- Limitar el número de conexiones a BBDD. Tanto a nivel de gestor como a nivel de php. En este caso, si como máximo vamos a tener 15 procesos, no tiene sentido dar más de 15 conexiones a BBDD. Como siempre, mejor "encolar" que ser "enculados" (no tiene gracia, pero bueno).
Con estos cambios más algunos a nivel de código que realizaron los desarrolladores (desde la parte de administración IT podemos hacer muchas cosas para mitigar, pero a fin de cuentas muchos de los problemas, si no casi todos -que no ha sido en este caso-, se solucionan desde la pantalla del programador) conseguimos que lo que fue una abrupta salida en producción se convirtiera dos días después solo en un problema, y al cabo de dos semanas en un problemilla.
Todavía hay muchas mejoras que se pueden hacer, sobre todo a nivel de cachés de Drupal y optimización de algunos componentes internos, pero a nivel de IT poco más se puede hacer. Y si alguien tiene alguna sugerencia que me la diga, que estoy completamente abierto a nuevos planteamientos.
Rendimiento en Drupal (I)
Recientemente hemos tenido una incidencia en un proyecto basado en Drupal debido a un problema grave de rendimiento. El site es un portal público con un gran número de accesos, y obviamente, al salir a producción emergió este problema.
Normalmente este tipo de situaciones no debería darse si se dimensionan unos benchmarks en condiciones, pero lamentablemente no fue este el caso. Un error muy común a la hora de definir benchmarks es no plantearlos adecuadamente.
Por un lado, hemos de diseñar unos casos lógicos de navegación. De poco basta definir una prueba de carga contra una home si luego la mayor parte de los usuarios se centran en dos o tres páginas concretas. Es importante, así pues, contar con una estadística de accesos al portal previo (caso de una actualización) o con una estimación lo más ajustada posible en caso de una nueva salida. Para este último caso se puede contar con un grupo de usuarios de control que, durante una temporada, hagan uso del portal para así generar un patrón de uso lo más realista posible.
Por otro lado, a la hora de diseñar los patrones de navegación es importante realizar varios patrones diferentes, incluir páginas diferentes en cada uno de esos patrones e incrementar lógicamente el número de hits sobre las páginas que van a ser accedidas con mayor frecuencia.
Todo esto y mucho más se puede realizar perfectamente con Jakarta JMeter.
Finalmente, y para el caso que nos ocupa, en el dimensionamiento de las pruebas, y este fue el GRAN ERROR, no se tuvo en cuenta que no es lo mismo un usuario anónimo que un usuario registrado. Estos últimos, por las características inherentes de Drupal, hacen que se haga flush del sistema de cachés por toda página sobre la que navegas.
El resultado es que aunque los test de carga daban un portal que podría soportar lo que fuera, a la hora de la verdad fue todo lo contrario.
En resúmen, es muy importante plantear y diseñar un sistema de pruebas de carga lo más realista posible a la hora de sacar un site a producción, especialmente cuando son sites sobre los que se va a tener una gran concurrencia.
Chrome en Linux
Hace ya algunos meses que las alphas de Chromium compilan en Linux y más que menos funcionan. Son realmente rápidas, pero además de incluir algunos bugs y funcionalidad sin terminar, no soportan plugins como flash, java y otros.
Si ya de por sí en Linux solemos tener problemas con algunos plugins creados en exclusiva para Windows, que encima los más comunes tampoco se soporten en Chromium hacen que el navegador quede relegado a pruebas o a sites donde queremos velocidad sin importarnos los dibujitos.
Pero esto ha cambiado. Desde hace muy poco, ya podemos igualmente hacer funcionar los plugins sobre Chromium, eso sí, añadiendo algo de inestabilidad al sistema.
Para ello basta con ejecutar Chromium desde línea de comandos:
chromium-browser --enable-plugins
Y automáticamente todo plugin de firefox estará disponible en Chromium (con sus ventajas y desventajas).
Para usuarios de Ubuntu y derivados, tenéis las builds disponibles en lauchpad como de costumbre.
2009/07/19
Virtualbox o VMware (player)
Virtualizar es algo realmente útil, especialmente para aquellos como yo que nos encanta trastear y nos vemos en la obligación en muchas ocasiones de utilizar software que no está preparado para funcionar en nuestro sistema operativo favorito (en mi caso, Linux).
Pero una vez puestos, hay que seleccionar el software de virtualización preferente. En mi caso, tras años de trabajar con VMWare, me he encontrado con una grata sorpresa al probar por pura curiosidad VirtualBox 3 de Sun.
VMWare, de siempre, ha contado con su VMWare Server, el cual da unas grandes prestaciones y hasta la fecha me ha servido realmente bien. Con la llegada de la versión 2.0 decidieron abandonar definitivamente la interfaz cliente nativa y se centraron en una interfaz web, dejando por otro lado el producto VMware Client como hasta la fecha.
El problema de VMware server, ahora, es que al levantar un servidor web es bastante más pesado que antaño, y además, este cliente es mucho más lento. Además, para tomar control sobre la máquina nos vemos obligados a usar el Add-on de Vmware para firefox, el cual tiene la peculiaridad de no funcionar sobre FF 3.5, el cual vengo usando en versión beta y RC desde hace meses. En resúmen, VMware orientó su VMWare Server para servidores y su VMWare client (productos separados) para ejecuciones locales. El problema viene con que además, VMWare client no te permite crear virtuales y es incompatible el tenerlo funcionando con VMWare Server, de forma que has de instalar VMware server, crear tu máquina virtual, desinstalar, instalar VMware Client y seguir a partir de este punto. Además ya no podrás tocar dicha máquina salvo que modifiques el .vmx a mano. No podrás crear nuevos discos (vmdk), no tendrás aceleración 3D (no es que me importe pero bueno)... en resúmen, te encontrarás con un producto capado que, aunque para la mayor parte de los mortales es más que suficiente, te obliga a desinstalar e instalar el Server a la hora de crearte una nueva máquina virtual.
La alternativa es VMware Workstation, que te permite hacer todo esto en una única aplicación... pero... hay amigo... es de pago. Y no nos gusta pagar cuando hay alternativas gratuitas y mucho menos piratear que es de mala gente (los que usan Windows y tal) :)
Al probar Sun VirtualBox me encontré con un producto muy similar a VMware Workstation, con un magnífico rendimiento y una consola "nativa" que me permite crear máquinas virtuales, tocar opciones, ejecutar máquinas, parar, reanudar, pasar a pantalla completa, etc, etc al igual que VMware Server en sus versiones 1.X.
Lo único que no trae VirtualBox que si trae VMWare (client) es la posibilidad de lanzar aplicaciones "en ventana" de forma que puedas lanzar, por ejemplo, Office directamente como aplicación en lugar de como máquina al completo, aunque en realidad la máquina virtual se ejecuta al completo pero solo te muestra la aplicación que te interesa. Esto está muy bien para usuarios finales que quieran tener la "sensación" de que están operando una aplicación nativa, pero no deja de ser una curiosidad.
Por otro lado, virtualbox hasta la fecha se me ha revelado bastante más sólido que VMware Server, el cual me colgó en un par de ocasiones la máquina.
Lo dicho. Me he pasado a VirtualBox, si bien para entornos corporativos sigo jugando en la liga de VMware... aunque claro, ESX Server, nada que ver con los productos de "andar por casa" que son VMware client y VMware server.
Pero una vez puestos, hay que seleccionar el software de virtualización preferente. En mi caso, tras años de trabajar con VMWare, me he encontrado con una grata sorpresa al probar por pura curiosidad VirtualBox 3 de Sun.
VMWare, de siempre, ha contado con su VMWare Server, el cual da unas grandes prestaciones y hasta la fecha me ha servido realmente bien. Con la llegada de la versión 2.0 decidieron abandonar definitivamente la interfaz cliente nativa y se centraron en una interfaz web, dejando por otro lado el producto VMware Client como hasta la fecha.
El problema de VMware server, ahora, es que al levantar un servidor web es bastante más pesado que antaño, y además, este cliente es mucho más lento. Además, para tomar control sobre la máquina nos vemos obligados a usar el Add-on de Vmware para firefox, el cual tiene la peculiaridad de no funcionar sobre FF 3.5, el cual vengo usando en versión beta y RC desde hace meses. En resúmen, VMware orientó su VMWare Server para servidores y su VMWare client (productos separados) para ejecuciones locales. El problema viene con que además, VMWare client no te permite crear virtuales y es incompatible el tenerlo funcionando con VMWare Server, de forma que has de instalar VMware server, crear tu máquina virtual, desinstalar, instalar VMware Client y seguir a partir de este punto. Además ya no podrás tocar dicha máquina salvo que modifiques el .vmx a mano. No podrás crear nuevos discos (vmdk), no tendrás aceleración 3D (no es que me importe pero bueno)... en resúmen, te encontrarás con un producto capado que, aunque para la mayor parte de los mortales es más que suficiente, te obliga a desinstalar e instalar el Server a la hora de crearte una nueva máquina virtual.
La alternativa es VMware Workstation, que te permite hacer todo esto en una única aplicación... pero... hay amigo... es de pago. Y no nos gusta pagar cuando hay alternativas gratuitas y mucho menos piratear que es de mala gente (los que usan Windows y tal) :)
Al probar Sun VirtualBox me encontré con un producto muy similar a VMware Workstation, con un magnífico rendimiento y una consola "nativa" que me permite crear máquinas virtuales, tocar opciones, ejecutar máquinas, parar, reanudar, pasar a pantalla completa, etc, etc al igual que VMware Server en sus versiones 1.X.
Lo único que no trae VirtualBox que si trae VMWare (client) es la posibilidad de lanzar aplicaciones "en ventana" de forma que puedas lanzar, por ejemplo, Office directamente como aplicación en lugar de como máquina al completo, aunque en realidad la máquina virtual se ejecuta al completo pero solo te muestra la aplicación que te interesa. Esto está muy bien para usuarios finales que quieran tener la "sensación" de que están operando una aplicación nativa, pero no deja de ser una curiosidad.
Por otro lado, virtualbox hasta la fecha se me ha revelado bastante más sólido que VMware Server, el cual me colgó en un par de ocasiones la máquina.
Lo dicho. Me he pasado a VirtualBox, si bien para entornos corporativos sigo jugando en la liga de VMware... aunque claro, ESX Server, nada que ver con los productos de "andar por casa" que son VMware client y VMware server.
2009/03/29
Actualizando a Debian 5 (lenny)
Hace poco que Lenny (Debian 5) vio finalmente la luz tras dos años de desarrollo.
Como siempre, nos dispusimos en mi empresa a abordar la a veces complicada y delicada tarea de migrar de una "major version" a la siguiente, y es que al igual que en el mundo Microsoft, en el mundo Linux los saltos hacia adelante nunca son sencillos.
Tras evaluar las posibles implicaciones de una actualización de esta magnitud, quedaron identificados como posibles principales fuentes de problemas los siguientes servicios: ldap, samba, openvpn y apache a través de php5. Como nota sobre esto último, decir que Debian 5 finalmente deja atrás el eterno php4 y solo trae soporte para php5. Debido a que muchas de nuestras aplicaciones en php nunca han sido testeadas en php5, lo hemos identificado como principal problema a resolver.
Hasta la fecha hemos actualizado todos los servidores de la DMZ, por ser los más expuestos, sin que hayamos encontrado ni un solo problema salvo el citado en php con los servicios que desde ellos se ofrecen: dns, smtp -via postfix-, proxy reverso (via apache) o servicio de páginas web, salvo una pequeña aplicación desarrollada in-house en la que encontramos un problema menor por los includes recursivos en php4 que fue rápidamente parcheada.
Dentro de la red interna, tampoco hemos tenido problemas con otros servicios críticos como puedan ser el dhcp en modo failover. Curiosamente el paso de samba 3.0.24 a samba 3.2 no ha tenido ni una sola complicación, y eso que usamos una configuración bastante complea con OpenLDAP como backend.
El principal problema que sí que hemos sufrido en nuestras carnes ha sido el paso de openldap 2.3 a opendap 2.4. Por motivos de compatibilidad hacia atrás (y un poco de vagancia) seguíamos trabajando con el eterno slurp. Y con Openldap 2.4 no funciona demasiado fino. Afortunadamente uno de mis chicos se puso manos a la obra y realizó los cambios para empezar a replicar con syncrepl, que por cierto funciona muchísimo mejor que slurp (realiza sincronizaciones completas desde cero) una vez solucionadas sus "peculiaridades".
Otros servicios como squid (proxy-cache), cvs y demás tampoco han dado el menor problema
Las bases de datos por ahora seguimos con postgresql-8.1, si bien debian5 ya no lo incluye y han pasado a postgres-8.3. Aquí el cambio es bastante delicado dado que postgres 8.3 si bien incluye potentes mejoras, también añade muchas restricciones a nivel de tipado en procedimientos almacenados o cambios profundos en los módulos de indexación textual (tsearch) por lo que la posible migración la abordaremos más adelante como proyecto independiente.
Ahora mismo nos centramos en los servidores que en breve actualizaremos, y que principalmente afectan a Gforge, subversion y el nodo principal de VPNs (openvpn). Con respecto a este último tenemos serias dudas debido al fix de la vulnerabilidad de las claves SSL en debian. Es posible que el nuevo daemon de VPN se niegue a usar dichos certificados, y esto nos podría generar el tener que rehacer todo el sistema. Es algo que habrá que abordar en algún momento.
En fin, si bien ya están actualizados cerca del 80% de los servidores bajo Debian 5, todavía nos queda un intenso 20% que iremos migrando en sucesivos días. Ya veremos con qué nos encontramos.
Como siempre, nos dispusimos en mi empresa a abordar la a veces complicada y delicada tarea de migrar de una "major version" a la siguiente, y es que al igual que en el mundo Microsoft, en el mundo Linux los saltos hacia adelante nunca son sencillos.
Tras evaluar las posibles implicaciones de una actualización de esta magnitud, quedaron identificados como posibles principales fuentes de problemas los siguientes servicios: ldap, samba, openvpn y apache a través de php5. Como nota sobre esto último, decir que Debian 5 finalmente deja atrás el eterno php4 y solo trae soporte para php5. Debido a que muchas de nuestras aplicaciones en php nunca han sido testeadas en php5, lo hemos identificado como principal problema a resolver.
Hasta la fecha hemos actualizado todos los servidores de la DMZ, por ser los más expuestos, sin que hayamos encontrado ni un solo problema salvo el citado en php con los servicios que desde ellos se ofrecen: dns, smtp -via postfix-, proxy reverso (via apache) o servicio de páginas web, salvo una pequeña aplicación desarrollada in-house en la que encontramos un problema menor por los includes recursivos en php4 que fue rápidamente parcheada.
Dentro de la red interna, tampoco hemos tenido problemas con otros servicios críticos como puedan ser el dhcp en modo failover. Curiosamente el paso de samba 3.0.24 a samba 3.2 no ha tenido ni una sola complicación, y eso que usamos una configuración bastante complea con OpenLDAP como backend.
El principal problema que sí que hemos sufrido en nuestras carnes ha sido el paso de openldap 2.3 a opendap 2.4. Por motivos de compatibilidad hacia atrás (y un poco de vagancia) seguíamos trabajando con el eterno slurp. Y con Openldap 2.4 no funciona demasiado fino. Afortunadamente uno de mis chicos se puso manos a la obra y realizó los cambios para empezar a replicar con syncrepl, que por cierto funciona muchísimo mejor que slurp (realiza sincronizaciones completas desde cero) una vez solucionadas sus "peculiaridades".
Otros servicios como squid (proxy-cache), cvs y demás tampoco han dado el menor problema
Las bases de datos por ahora seguimos con postgresql-8.1, si bien debian5 ya no lo incluye y han pasado a postgres-8.3. Aquí el cambio es bastante delicado dado que postgres 8.3 si bien incluye potentes mejoras, también añade muchas restricciones a nivel de tipado en procedimientos almacenados o cambios profundos en los módulos de indexación textual (tsearch) por lo que la posible migración la abordaremos más adelante como proyecto independiente.
Ahora mismo nos centramos en los servidores que en breve actualizaremos, y que principalmente afectan a Gforge, subversion y el nodo principal de VPNs (openvpn). Con respecto a este último tenemos serias dudas debido al fix de la vulnerabilidad de las claves SSL en debian. Es posible que el nuevo daemon de VPN se niegue a usar dichos certificados, y esto nos podría generar el tener que rehacer todo el sistema. Es algo que habrá que abordar en algún momento.
En fin, si bien ya están actualizados cerca del 80% de los servidores bajo Debian 5, todavía nos queda un intenso 20% que iremos migrando en sucesivos días. Ya veremos con qué nos encontramos.
2009/03/23
Ubuntu Jaunty, primeras impresiones
Desde hace casi un mes estoy trabajando diariamente con Ubunty Jaunty.
¿Que por qué ando trasteando con una Alpha? Pues simplemente porque hice el canelo y cambié mi partición primaria a ext4, de forma que luego desde Intrepid no podía arrancar.
Y como ya no estoy para andar con recompilaciones de kernel cada dos por tres y demás, directamente decidí probar Jaunty.
¿Impresiones?
Ext4 se nota, y se nota bastante. Sobre todo en el arranque y luego en lo que es el uso del sistema operativo día a día. Va más fluído. No pensé que un cambio en un sistema de archivos pudiera notarse tanto, pero he de reconocer que esta vez así ha sido. Tiene alguna pega, como un puñetero bug que hace que con determinadas aplicaciones que no utilizan la llamada fsync puedas perder datos si apagas o reinicias sin haber esperado un ratito, pero afortunadamente no he sufrido este problema.
En cuanto al sistema en sí, han metido novedades en Gnome 2.26. Ahora las notificaciones salen en mensajes emergentes muy bonitos en la barra de programas. Muy interesante y mucho más usable.
La única pega es que sigo sufriendo los cuelgues cuando entra el screensaver y compiz está activo, pero tiene que ver más con el driver para X de la tarjeta intel que trae mi portátil que otra cosa. Es fácil de solucionar: fuera compiz y screensaver en negro... poco se pierde.
Teniendo en cuenta que vamos por la Alpha6?, creo que esta release de Ubuntu va a salir muy redonda y realmente va a merecer la pena. Además viene ya con Openoffice 3.0.1 de serie.
¿Que por qué ando trasteando con una Alpha? Pues simplemente porque hice el canelo y cambié mi partición primaria a ext4, de forma que luego desde Intrepid no podía arrancar.
Y como ya no estoy para andar con recompilaciones de kernel cada dos por tres y demás, directamente decidí probar Jaunty.
¿Impresiones?
Ext4 se nota, y se nota bastante. Sobre todo en el arranque y luego en lo que es el uso del sistema operativo día a día. Va más fluído. No pensé que un cambio en un sistema de archivos pudiera notarse tanto, pero he de reconocer que esta vez así ha sido. Tiene alguna pega, como un puñetero bug que hace que con determinadas aplicaciones que no utilizan la llamada fsync puedas perder datos si apagas o reinicias sin haber esperado un ratito, pero afortunadamente no he sufrido este problema.
En cuanto al sistema en sí, han metido novedades en Gnome 2.26. Ahora las notificaciones salen en mensajes emergentes muy bonitos en la barra de programas. Muy interesante y mucho más usable.
La única pega es que sigo sufriendo los cuelgues cuando entra el screensaver y compiz está activo, pero tiene que ver más con el driver para X de la tarjeta intel que trae mi portátil que otra cosa. Es fácil de solucionar: fuera compiz y screensaver en negro... poco se pierde.
Teniendo en cuenta que vamos por la Alpha6?, creo que esta release de Ubuntu va a salir muy redonda y realmente va a merecer la pena. Además viene ya con Openoffice 3.0.1 de serie.
2009/02/24
A correr se ha dicho.
Este sábado 22 de Febrero, y para celebrar mis 33 años, me propuse correr mi primera media marathon...
Hasta la fecha he corrido muchas carreras de 10km, tipo San Silvestre y similar, con unos tiempos bastante aceptables (por debajo de los 45 minutos). Y dado que hace tiempo que no sufro "contratiempos" (tendinitis, sobrecargas y monerías por el estilo) decidí animarme a por los 21.1km de la media, con mucho miedo y muy tranquilito, eso sí.
Me fui con un buen amigo (Luisín) que suele ser compañero de este tipo de locuras, y allí nos plantamos, a las 10 de la mañana para correr la Media Marathon de la Latina, con un perfil complicado (muchas subidas y bajadas), muchas ganas, y un poco de acojone.
Al final terminé, mucho menos hecho polvo de lo que pensaba, enterito y sin que la rodilla llorara (se quejó una vez pero se quedó solo en eso) y con un tiempo más que digo, 1h 46 minutos....
Próxima parada: Media Marathon de Madrid.
P.D: Realmente llegué (221).
Hasta la fecha he corrido muchas carreras de 10km, tipo San Silvestre y similar, con unos tiempos bastante aceptables (por debajo de los 45 minutos). Y dado que hace tiempo que no sufro "contratiempos" (tendinitis, sobrecargas y monerías por el estilo) decidí animarme a por los 21.1km de la media, con mucho miedo y muy tranquilito, eso sí.
Me fui con un buen amigo (Luisín) que suele ser compañero de este tipo de locuras, y allí nos plantamos, a las 10 de la mañana para correr la Media Marathon de la Latina, con un perfil complicado (muchas subidas y bajadas), muchas ganas, y un poco de acojone.
Al final terminé, mucho menos hecho polvo de lo que pensaba, enterito y sin que la rodilla llorara (se quejó una vez pero se quedó solo en eso) y con un tiempo más que digo, 1h 46 minutos....
Próxima parada: Media Marathon de Madrid.
P.D: Realmente llegué (221).
Casi dos años abandonado...
Bueno, tras dos años con el blog prácticamente abandonado vamos a ver si retomamos la sana costumbre de ir añadiendo algún articulillo aunque sea de vez en cuando.
La excusa que tengo es perfecta. No, no me he tomado un par de años sabáticos, más quisiera yo. La verdad es que tener un enano es una labor muy muy ardua que te deja muy poquito tiempo libre para otras muchas cosas. Y claro, hay que priorizar. Y el escribir articulillos suele ser de lo primero que se sacrifica.
Así pues, vamos a ver si nos volvemos a poner las pilas, porque la verdad es que en estos dos años han pasado muchas cosas, y empezamos a darle un poco más de vida al blog. :-)
La excusa que tengo es perfecta. No, no me he tomado un par de años sabáticos, más quisiera yo. La verdad es que tener un enano es una labor muy muy ardua que te deja muy poquito tiempo libre para otras muchas cosas. Y claro, hay que priorizar. Y el escribir articulillos suele ser de lo primero que se sacrifica.
Así pues, vamos a ver si nos volvemos a poner las pilas, porque la verdad es que en estos dos años han pasado muchas cosas, y empezamos a darle un poco más de vida al blog. :-)
Suscribirse a:
Entradas (Atom)