Hace unas cuantas semanas, con las últimas actualizaciones de PLESK (9.2.3 y 9.3.0), cayó en nuestras manos, en nuestros servidores una pequeña petada del antivirus que también incluye Parallels cuando actualiza sus versiones: el Drweb.

Y es que de golpe y porrazo, el Dr.Web no solo envía un correo cuando hay algún problema en la actualización de su base de datos, sino que lo hace cada hora, pase lo que pase, sea correcta o no esa actualización de virus conocidos.

Además, los correos los envía a drweb@nombre_del_host.com , cuenta de correo que nadie tiene creada. Si tienes un solo servidor, quizás te cueste poco crear ese email, pero si virtualizas tu máquina y tienes unos cuantos VPS, entonces sería un suplicio ponerte a ello, además de tener en cuenta que todo eso es tráfico y ancho de banda.

La solución pasa por modificar el fichero /etc/drweb/drweb32.ini en la línea
CronSummary = {Yes | No}

Poniendo No en lugar de Yes.

Via: After upgrade Parallels Panel to version 9.2.3 Dr.Web notification deliveries start failing

Es decir, tendrás el servidor petado y al final habrás preferido tener un tráfico intermedio, porque al menos no te daba problemas. Espero que no lo hayas pensado en serio

Para incrementos de tráfico razonables, hay varias soluciones:
1/ El más simple, es reducir el peso de tu web y el número de querys a la base de datos y de llamadas a Apache.
2/ Instalar xCache u otro acelerador de php a nivel servidor.
3/ Tunear MySQL (escribiré un post sobre eso en breve)
4/ Tunear Apache (tengo otro post pendiente)

Pero cuando hay un incremento brutal de tráfico como nos ha pasado a nosotros en nuestro blog de mujer, la cosa se pone fea si no se adoptan otro tipo de medidas: Distribuir la carga entre 3 máquinas o VPS, ya que es Apache quien no es capaz de servir adecuadamente las páginas por mucha máquina que tengas.

Servidor 1/ Aquí estará la instalación inicial de WP. Mysql lo apagamos, dejamos correr Apache.
Servidor 2/ Tendremos solo Apache y una copia exacta de la instalación del Worpdress del primer servidor.
Servidor 3/ Solo Mysql. El resto de servicios apagados.
En el servidor 1 y 2, por supuesto debes configurar correctamente el xCache.

Esta es la idea. Ahora vamos a ver como ponerla en práctica:

Hay cuatro pasos:
1/ Instalación normal del Wordpress en el servidor 1
2/ Cambio del Mysql al servidor 3
3/ Duplicación del contenido entre los servidores 1 y 2
4/ Balanceo y sincronización entre los servidores 1 y 2.

El paso 1.
Ni lo menciono. Te instalas tu wordpress y andando, como si nada.

El paso 2.
-  Crea un usuario y base de datos en el servidor 3.
-  Vuelca el contenido del MySQL desde el servidor 1 al servidor 3. Nosotros utilizamos el software MySQLFront. Hace la migración de la estructura y datos, rápido y bien. Yo no me complicaría la vida con comandos por SSH.
- Modifica el wp-config.php y en las líneas en las que configurar la base de datos, coloca la IP, usuario, base de datos y claves que tengas en el MySQL del servidor 3.

Asegúrate de que esa base de datos es accesible desde fuera del propio servidor. Si no sabes como se hace te recomiendo este post y este otro artículo.

Hecho esto, el apache responderá al Servidor 1 y MySQL al servidor 3.

El paso 3.
El dominio en cuestión que utilices ya está dado de alta en el servidor 1 de forma normal.
A la hora de darlo de alta en el nuevo servidor, puedes crearlo manualmente o si utilizas PLESK, utilizar el comando Migrar. Vamos a ver como sería en cada caso:

A/ Manualmente:
- Ahora da alta en el servidor 2 el mismo dominio, como si no existiera el primero.
- Accede por SSH al servidor 2. Comprueba que las rutas son las que deben ser, es decir las mismas que el servidor 1. Solo necesitamos volcar el contenido tal y como está en el servidor 1.

Para eso utilizamos el comando scp . Accede al servidor 1 por ssh, haz un tar del contenido del dominio. Luego accede al servidor 2 por ssh. Sitúate en el mismo directorio donde has hecho el tar en el otro servidor e introduce el comando:

scp root@ip-servidor1:/var/www/vhost/dominio.com/httpdocs/backup.tar .

Modificando la ip y las rutas en tu caso. Destargetea el backup y ya tienes tu contenido.

B/ Utilizando el Migrar de PLESK9.
Vas al servidor destino y utilizas el comando Migrar. Espera a que haya terminado la migración y comprueba el log de errores si que falla algo.

Hayas utilizado el procedimiento que hayas usado:
- Borra todas las DNS creadas por el servidor por defecto (en PLESK 9: Desactivar servicio)
- Crea manualmente los registros DNS de las dns que resuelvan el dominio en cuestión.
Es decir si en tu registrador tienes ns1.servidordenombres1.com y ns1.servidordenombres2.com , debes agregar esos dos registros ns, para indicarle al dominio quien va a resolver la ip del dominio son esos DNS.
- Desactiva el servicio de correo del servidor si lo tenías activado.

Ahora tenemos que volver al panel del servidor 1 y añadir una línea en las DNS.
Verás que ahora tienes un IN A www.dominio.com  a la ip del servidor 1. Debes duplicarla colocando la ip del servidor 2. De ese modo, cuando alquien llegue al dominio, puede responder una u otra ip y balancear de ese modo la carga entre ambos servidores.

Resetea Named y Apache y en unos minutos empezarás a recibir tráfico en la segunda máquina.
¿Como puedes saberlo? Accede por ssh al servidor 2 e introduce el comando


watch 'netstat -anp | grep :80 | wc -l '


De devolverte valores casi cero, pasará a mostrarte el núemro de sesiones de apache abiertas. Eso siginifica que ya empieza a responder a algunas llamadas. De todos modos, el balanceo no será proporcional hasta que pasadas 12/24 hora, se propaguen bien las dns.

El paso 4.
Ya tenemos un servidor solo para las bases de datos y la carga de Apache balanceada. Notarás la mejoría en el tiempo de respuesta de tu web, una salvajada. De repente verás como el tráfico de tu web sube y no es real, esas visitas de más son las que no eras capaz de servir por falta de máquina antes de poner en marcha todo esto.

Ahora nos falta sincronizar los contenidos.
Aqui tengo que dar las gracias a Francisco Monteagudo, por su post.  No tienes más que seguir la última parte al pie de la letra que copio aquí:

1. Desde la línea de comandos del servidor linux primario, ejecutamos: ssh-keygen -t rsa -b 4096 -f /root/.ssh/id_rsa
2. El comando anterior nos pedirá que introduzcamos una passphrase; la dejamos en blanco.
3. Ahora, en el directorio de configuración del ssh del usuario root tendremos dos ficheros, id_rsa que contiene la clave privada y id_rsa.pub que contiene la clave pública.
4. Copiamos la clave pública al servidor linux secundario, al directorio /root/.ssh
5. En el servidor secundario, vamos al directorio /root/.ssh y buscamos el fichero “authorized_keys”. Si el fichero no existe, entonces renombramos el fichero id_rsa.pub que hemos copiado del servidor primario. Si existe, lo editamos y el fichero id_rsa.pub lo añadimos como última línea.
6. Ahora volvemos al linux primario y creamos el siguiente script:
   

   #!/bin/sh
   rsync -avz secundario:/directoriouploads2 /directoriouploads1
   rsync -avz /directoriouploads1 secundario:/directoriouploads2 

   Siendo:

   • secundario: Dirección IP del servidor secundario.
   • directoriouploads1: Directorio de uploads de wordpress en el linux primario.
   • directoriouploads2: Directorio de uploads de wordpress en el linux secundario.
7. Creamos una entrada en el crontab del linux primario para que el script anterior se ejecute cada hora.

Mi recomendación es si tienes un cache de WordPress tipo 1Bloger, SuperCache, etc es que los desactives, a no ser que ejecutes la sincronización cada minuto, pero me parece demasiado.

Otra recomendación es que los editores siempre trabajen con el servidor 1. Para que no le responda unas veces el 1 y otra sel 2, debes modificar el archivo hosts que tienes en tu ordenador en la ruta  C:\WINDOWS\system32\drivers\etc\hosts , añadiendo una linea donde le indiques que para ese dominio debe acudir a la IP del servidor 1.

Creo que no me dejo nada. Si crees que se puede hacer de otro modo, te agradecería que hicieses un comentario.

1/ Instalar el administrador para ver el panel por web
Cuando explicaba como instalar el script, al final de todo, comentaba como ver a través de web el panel de administración del xcache. Te recomiento que una vez compruebes que todo está correctamente instalado, crees el panel de forma urgente (luego se te olvidará), porque ahí es donde vamos a poder ver cosas que nos den pistas de como está funcionando xCache.

2/ Funcionalidades del panel de xcache
Al acceder al panel vas a ver tres cosas:
a/ Statistics: Estadisticas y parámetros de configuración
b/ List PHP: Listado de archivos php cacheados
c/ List Var Data: Creo que se refiere a variables cacheadas, pero ni lo tengo claro, ni lo he activado.

3/ Parámetros a configurar
Para configurar los parámetros, deja correr el script al menos 5 minutos para que empiece a tomar datos y ver cosas.

a/ xcache.count
Se refiere al número de partes en als que deseas dividir el cache. Se la relaciona con el número de procesadores que tienes en tu servidor. Lo habitual es colocar nº de procesadores + 1. Puedes ver cuantos tienes en tu servidor o VPS , con el comando:
cat /proc/cpuinfo |grep -c processor


b/ xcache.size
Es uno de los parámetros clave. Fíjate en la columna OOMs (Out of Memory). Todos los valores deberían ser CERO. Si tienes valores muy bajos no deberías preocuparte demasiado, pero vigílalo. Generalmente o van a ser CERO o van a ser muy altos.

Si son altos significa que xcache hace un esfuerzo enorme y la memoria asignada no es suficiente, asi que casca (Out of memory) . Puedes ir subiendo el parámetro xcache.size .  Yo lo hago en múltiplos de 32M. De entrada puedes ponerle 64M que no pasará nada, pero tampoco debes asignarle demasiada, porque dejarás de ofrecer memoria al servidor para ejecutar otros procesos ajenos a xcache.

c/ xcache.slots
Todavía no tengo claro que es exactamente, pero lo hemos subido de 8k a 16k y hemos notado mejoras. Siempre que lo subas, debes saber que consumirá más memoria, asi que como siempre dependerá de la máquina o VPS que tengas.

d/ xcache.ttl y xcache.gc_interval
Me falta hacer pruebas con dos parámetros que también pueden ser importantes, que son xcache.ttl y xcache.gc_interval que se refieren a cada cuantos segundos se refresca el caché o se purga. Si tengo nuevos datos lo publicaré.

e/ parámetros _var
Respecto a los parámetros _var yo de momento no los tocaría. No he visto nada ni nadie que hable de ellos y al activarlo para hacer pruebas hemos perdido prestaciones.

4/ Más cosas a tener en cuenta
Además de configurar el fichero xcache.ini, debes tener en cuenta que para mejorar todavía más el rendimiento de tus webs, deberías optimizar la confioguración del propio apache  e incluso el del servidor mysql (eso es otra historia) y por supuesto dependerá de la máquina que tengas.

Tienes la doc. oficial de los parámetros en la web oficial:
http://xcache.lighttpd.net/wiki/XcacheIni

Si haces pruebas y obtienes conclusiones, me encantaría que las pudieras compartir conmigo, lo publicaré y lo compartiré con los demás.

1. Descargar la última versión estable desde SSH:
En mi caso ha sido la 1.3.0

# cd /usr/bin/
# wget http://xcache.lighttpd.net/pub/Releases/1.3.0/xcache-1.3.0.tar.gz


2. Descomprimir

# tar -zxvf xcache-1.3.0.tar.gz
# cd xcache-1.3.0


3. Compilar xcache

# phpize
Aqui tuve mis primeros problemas, ya que no tenía instalada la librería necesaria para ejecutar phpize. Si te sucede lo mismo, debes instalar la librería php-devel . Yo lo hago desde el PIM del servidor, pero puedes hacerlo con el yum.


# ./configure --enable-xcache
Al llegar aquí volví a tener problemas para compilar el código en C. Al intentarlo devuelve el error:
configure: error: no acceptable C compiler found in $PATH
se soluciona fácilmente instalando la librería gcc.


# make
Otra vez problemas. Me devuelve el error:
/usr/include/php/ext/date/lib/timelib_structs.h:24:28: error: timelib_config.h: No such file or directory

Esto si que es mucho más extraño. Solo si te devuelve este error, debes editar el fichero /usr/include/php/ext/date/lib/timelib_structs.h y modificar la linea #include <timelib_config.h> por #include "timelib_config.h" . Simplemente cambiando el corchete por comillas.

Yo lo hago con el joe, pero lo puedes hacer con vi o culaquier editor
# joe /usr/include/php/ext/date/lib/timelib_structs.h

Continuamos con la compilación
# make install

Esto lo que va a hacer es generar un fichero xcache.so que por defecto se instala en la ruta:
/usr/lib64/php/modules/xcache.so

4. Crear xcache.ini
Esta parte se puede hacer de dos formas o bien introduciendo todas las variables en el php.ini o creando el fichero xcache.ini . Yo he preferido hacerlo de la segunda forma.

# cd /etc/php.d/
# joe xcache.ini


como el fichero no existe, debes pegar lo siguiente:


[xcache-common]
; change me - 64 bit php => /usr/lib64/php/modules/xcache.so
; 32 bit php => /usr/lib/php/modules/xcache.so
zend_extension = /usr/lib64/php/modules/xcache.so

xcache.cacher = On
xcache.stat = On


5. Configurar xcache.ini
xcache te permite acceder a un panel de control a través de web, para ver las estadísticas de cacheo, urls, ratio de compresión de los php, etc. Para ello debemos introducir en xcache.admin.pass = “” el password con el que vamos a querer acceder a ese panel.

Ojo, el password ha de estar encriptado en MD5, por lo que necesitarás una herramienta online o algo similar que lo codifique. Por ejemplo, el MD5 del password “hola” es “4d186321c1a7f0f354b297e8914ab240″ . Esto último es lo que debes poner en esa variable del xcache.ini

Hay un ajuste más que debes hacer.
cat /proc/cpuinfo |grep -c processor
Esto te dice el número de procesadores que tienes en el servidor o VPS y debes colocarlo en la variable xcache.count = del xcache.ini , en nuestro caso xcache.count = 3

6. Reiniciamos Apache
# service httpd restart

7. Comprobamos que todo ha ido bien
# php -v

Si todo ha ido bien, debería devolver los parámetros de la actual instalación de PHP y deberías ver la línea “XCache v1.3.0, Copyright (c) 2005-2007, by mOo”

8. Creamos el panel de control
Copiamos el directorio /usr/bin/xcache-1.3.0/admin al directorio donde quieras verlo a través de la web. Es decir, si en ese servidor tienes un dominio www.dominio.com y su ruta es /var/www/vhosts/dominio.com/httpdocs/ , deberás crear ahí un directorio admin y copiar el contenido original. De ese modo desde www.dominio.com/admin accderás con el user=”admin” y el pass que has colocado en el paso 5.

# mkdir /var/www/vhosts/dominio.com/httpdocs/admin
# cp -R admin/* /var/www/vhosts/dominio.com/httpdocs/admin/

Nosotros en nuestro web del eurobasket, hemos notado nada más instalarlo una mejoría brutal en la velocidad de acceso. En algunas páginas como las “resultados eurobasket” o “calendario eurobasket” el cacheo ha sido espectacular ya que han sido unas de las mas vistas. No creo que sea casualidad tampoco que desde hoy hayamos duplicado el tráfico de estos días.

Además de llevar toda la parte de gerencia en cada área de negocio, hay dos cosas para las que intentaré sacar tiempo de aquí a final de año: Analítica Web y Optimización y mejora del rendimiento de los servidores.

Por un lado, la analítica web es una pieza fundamental para entender que está pasando en una web, porqué, y que va a seguir pasando si no se toman medidas. Cuando se trabaja en comercio electrónico, como en nuestro caso con mundobebes.net, cambia el punto de vista que tienes de las estadísticas web.

Ahora ya no sirve tener una buena tasa de click de las campañas SEM, al menos a nosotros nos dice bastante poco, necesitamos saber que convierte para cada tipo de campaña / producto y para cada tipo de procedencia del usuario. ¿Que landings generan más ventas? ¿Las campañas SEM funcionan igual para todos los productos? ¿Cual es la tasa de rebote en cada caso? ¿es equitativo la tasa de rebote con las ventas dependiendo de su procedencia? ¿y dependiendo del tipo de navegador utilizado? ¿y dependiendo de si tienen o no pantalla grande o pequeña?  Todo eso y mucho más es analítica web y me ha entrado el gusanillo. Soy consciente de que muchos competidores se gastan una pasta en publicidad, pero realmente no la rentabilizan y eso es una ventaja competitiva para nosotros.

Respecto al segundo punto, muy muy técnico. De forma interna, estamos inmersos en un profundo cambio de tecnología. En unas semanas ofreceremos VPS, algo muy común ahora mismo, pero no queremos ser uno más. Hoy cualquiera puede tener un servidor y montar Virtuozzo PLESK y ofrecerlo a cliente, pero ¿con que configuraciones? ¿con las estandard?  nosotros queremos que nuestros productos de hosting rindan más que lo común. ¿Eso como se hace? Probando, reconfigurando y adaptando parámetros de MySQL, apache o PHP, midiendo y optimizando el rendimiento de los servidores.

No podemos olvidar que por un lado la mejora de la velocidad de una web, mejora la fidelidad de los usuarios y es un plus para el posicionamiento. Por otro lado, no se trata de traer muchos clientes a una web, sino de ser capaz de seleccionar a aquellos que potencialmente más te van a comprar. Con estas dos cosas y alguna más que todavía está en el taller, trataremos de sino duplicar, al menos multiplicar por 1,5 en 2010 la cifra de negocio de 2009, en nuestra tienda de bebes.

A eso de las 09:45 comencé a notar problemas con los servidores. Enseguida me di cuenta de que era un problema de conectividad y contacté con quien puede ayudarnos en estos casos.

David Carrero, me confirmó que los impresentables de Iberdrola (otra vez) la habían cagado con la fibra. Les pasa poco, pero cada vez que ocurre la lian muy gorda.

Como todas nuestras aplicaciones están en web, apenas pude hacer nada y me conecté a FaceBook y Twitter y pude estar en contacto sobre todo con David Carrero, que a pesar de estar de viaje y en un congreso estuvo al pié del cañón y reportando en todo momento cual era la situación.

Así que mientras esperaba he ido descubriendo cosas de twitter que me han gustado. Seguiré probando.
A las dos horas ha quedado todo resuelto. Gracias por todo David!

Lo primero que has de hacer es descargarte el loader adecuado desde la página de descarga de ionCube.
Lo habitual para Servidores Linux es utilizar el paquete Linux (x86).

Aunque el ionCube tiene un autoinstalador, te recomiendo que si tienes acceso al php.ini lo hagas siguiendo las siguientes instrucciones, aunque es un poco rollo estarás seguro de hacerlo bien.

1/ Crea un directorio /ioncube/ en el hosting del dominio donde vas a hacer correr el script.
2/ Ejecuta www.tudominio.com/ioncube/ioncube-loader-helper.php
3/ si ya lo tienes instalado, te dirá “An ionCube encoded file has been loaded successfully.”
Si no lo tienes instalado te da dos opciones. Como digo, si tienes acceso al php.ini escoge la primera.

En pantalla te mostrará un análisis de tu servidor (versión de apache, versión de php, … y lo más importante: el fichero de ionCube que necesitas para hacer correr aplicaciones codificadas.
Si por ejemplo tienes instalado el PHP 4.3.10 , será el fichero ioncube_loader_lin_4.3.so

 4/ Como lo mejor es instalar ionCube a nivel servidor y no depender de un dominio determinado, debemos mover todo a un diectorio que sepas nunca vayas a borrar, ya que si en unos meses borras ese dominio desinstalarías todo.

Te recomiendo mover todos los ficheros de la carpeta /ioncube que habías volcado a tu dominio al directorio /usr/local/ioncube , de manera que en nuestro caso tengas el fichero en la ruta /usr/local/ioncube/ioncube_loader_lin_4.3.so

5/ Solo queda modificar el php.ini . Haz una copia antes de nadapor si te equivocas y edita el php.ini
Debes añadir una línea que contenga

zend_extension = /usr/local/ioncube/ioncube_loader_lin_4.3.so

O el nombre del fochero que te corresponda según la versión de php tengas.

6/ Para finalizar, resetea Apache y a disfrutar del script.