Algunos de los artículos de este sitio tratan sobre la optimización de servidores web.

Ya conocia el proyecto Nginx y lo habia utilizado parcialmente tal como esta señalado en post previo usando redirecciones con .httaccess

Encontré hace un par de dias la solución perfecta para hacer convivir el Apache en Plesk y el Nginx sacando provecho de lo mejor de ambos.

Sigue leyendo y descubrirás como integrar perfectamente el Nginx con tu Plesk

La primer parte es instalar el Nginx. Puedes hacerlo de la manera tradicional bajando la fuente e instalandolo a mano.

para este ejemplo usaremos el rpositorio de rpms de ART

En mi caso uso RHEL pero ART tambien hace rpms para Fedora y Centos.

La manera más fácil de instalar el repositorio de ART en tu servidor plesk con Fedora/Centos/RHEL es usando el comando:

wget -q -O - http://www.atomicorp.com/installers/atomic.sh | sh

una vez instalado el repositorio instalar Nginx es tan sencillo como

yum install nginx

La ventaja de hacerlo de esta manera es que el rpm te ayuda con la instalación correcta y activacion como servicio.

una vez instalado  descarguen este archivo ZIP y descomprímanlo en la carpeta /etc/nginx/ sobreescribiendo los archivos que asi lo soliciten.

una ves descomprimido el contenido de ese zip ejecuten el siguiente comando:

sh /etc/nginx/<code>generate_nginx_conf.sh

lo cual leerá la configuracion del apache modificada por el Plesk y generará los scripts correspondientes de nginx para cada dominios existente en el servidor. ( En el caso de un plesk normal en un servidor dedicado con varios ips no fue necesaria modificación alguna de los templates que vienen en el zip ).

Ahora de momento nos enfocaremos en los cambios necesarios del Apache. La idea es que el Nginx se quede escuchando en el puerto 80 y el apache en algun otro puerto…. digamos el 8080…

El Nginx servira contenido estático y todo el contenido dinámico lo pasará al apache liberando a este ultimo del servicio de imágenes y anexos para lo cual es mas eficiente el Nginx.

Como cambiar el Apache de plesk de puerto y no morir en el intento:
/usr/local/psa/admin/sbin/websrvmng --set-http-port --port=8080
/usr/local/psa/admin/sbin/websrvmng --reconfigure-all
/usr/local/psa/admin/sbin/webmailmng --disable --name=horde
/usr/local/psa/admin/sbin/webmailmng --enable --name=horde
/usr/local/psa/admin/sbin/webmailmng --disable --name=atmail
/usr/local/psa/admin/sbin/webmailmng --enable --name=atmail
/usr/local/psa/admin/sbin/webmailmng --disable --name=atmailcom
/usr/local/psa/admin/sbin/webmailmng --enable --name=atmailcom
service httpd restart
service nginx restart
Fimalmente les recomiendo que configuren el Nginx para que arranque al inicio del equipo con el comando:

chkconfig –level 345 nginx on

Y listo!!!! Nginx esta funcionando ahora en el puerto 80 y el apache esta feliz ahora en el puerto 8080 y todo funciona de maravilla.

La implementacion del Nginx puede ayudarte a usar al maximo los recursos de tu servidor, ya que nginx usa significativamente mucha menos menoria ram que los procesos comunes de apache y por lo tanto te da la oportunidad de entregar mas paginas/contenido utilizando el mismo hardware.

Este proceso de sustitucion es altamente recomendado si tu sitio tiene constantes y continuas cargas altas debidas a trafico Web.

Nota: El puerto 8080 es usado regularmente por una parte el Tomcat, si no usas Tomcat en ese servidor, simplemente desactivalo para que no tengas problema alguno con el Apache.

chkconfig --level 345 tomcat5 off

service tomcat5 stop

Revisa tambien que el servicio de Tomcat no este monitoreado por el módulo de Watchdog, de ser así desactívalo en el módulo para que el Watchdog no lo arranque de nuevo.

Esto es comúnmente es llamado seguridad por obscuridad y no debería confiar sólamente en esto, es sólo una de las muchas cosas que puede hacer para ayudar a minimizar las posibilidades de que un servidor sea hackeado.

Primero desabilitaremos la información de versión en el Apache.

—–comando—–
emacs /etc/httpd/conf/httpd.conf
—–comando—–

Presiona control + s para buscar “ServerSignature“
Seguramente dice On, cámbialo a Off
Esto remueve la identificacion de versión del Apache en las páginas de error.

Justo abajo de esa linea agrega otra que diga:

ServerTokens Prod
Esto identificará al Apache simplemente como eso… “apache” sin los números de version o datos del sistema operativo

Salva el archivo ( Control + S y Control + X ) y reinicia el apache

—–comando—–
service httpd restart
—–comando—–

Ahora desabilitaremos el named para que no dé version

—–comando—–
emacs /etc/named.conf
—–comando—–

Busca “query-source address * port 53;”
Agrega una línea justo abajo que diga:

version “Named”;

Salva y reinicia el servicio named

Recuerda que esto sólo es seguridad por obscuridad y aun asi necesitarás actualizar el servidor. Esto sólo va a detener a algunos de encontrar tu server en primera instancia usando escaneos automáticos. No te ayudará en nada si alguien esta tratando de entrar al servidor.

El server es un Celeron 1.7 con 512 MB RAM y cada uno de los sitios andan por el orden de varios de miles de hits al dia.

Despues de experimentar varios dias con estos problemas encontré una mezcla de soluciones que me permitio que el server no se caiga y mantenga el paso con las peticiones de clientes…

• Instala eaccelerator para reducir la carga al compilar las paginas php. UPDATE Jul 2009 ( Ahora uso Xcache en lugar de Eaccelerator)
• Desactiva el logging en el apache: si tienes trafico alto los logs pueden causarte pesadillas por el uso de disco. Al desactivarlo permites que se entreguen archivos mas rapidamente.
• Descargué e instale Litespeed Webserver ( yo usé la version Standard, libre pero solo llega hasta 300 clientes concurrentes.. si son necesarios más… tendrias que comprar la version enterprise y ya no te costea $500 USD ) y lo configuré para correr en un puerto alto (8080) importando las configuraciones de virtual hosting del apache.
• Usé una regla de redirección para que todo el contenido estatico ( imagenes, videos y swf ) sean redireccionados al servidor recien instalado en el puerto alto (8080)

Esto puede ser configurado directamente en el httpd.conf o un .htaccess en el directorio publico. ( Yo normalmente lo pongo en un .httaccess en la carpeta donde esta mi sitio mas usado )
RewriteEngine on
RewriteRule .*\.(gif|GIF|jpg|JPG|png|PNG|swf|SWF|pdf|PDF)$ http://%{HTTP_HOST}:8080%{REQUEST_URI}

(Son dos lineas )

• Activa las opcionesde compresion en /etc/php.ini

output_buffering = On
output_handler = ob_gzhandler

• Como ya no estoy enviando contenido estático con el apache, desactivo las opciones de Keepalive, ajusto MaxRequestsPerChild a un valor alto, MinSpareServers 10 MaxSpareServers 20 y StartServers a un valor inicial medio ( yo usé 80 )

El webserver en el puerto alto hace parte de la magia, corre practicamente sin demasiada memoria ( 20MB en horas pico pero solo en un proceso ) y sirve hasta 300 usuarios concurrentes con un gasto minimo de CPU ( mucho menos del 1% ), Apache aun sigue enviando contenido dinámico, usando esta combinación Apache aún usa de 10 a 20 MB de RAM por proceso pero el tiempo que un cliente utiliza el Apache es menor que en una configuración tradicional, esto reduce la concurrencia de clientes en el Apache.
Los cambios en KeepAlive permiten que el apache termine una peticion y atienda la siguiente sin esperar peticiones extra del cliente. ( las cuales son atendidas por el otro servidor ) bajando asi el numero de clientes concurrentes usando Apache

Estos ajustes redujeron dramaticamente la carga de el servidor
Ahora el server tiene un promedio de carga muy diferente…
load average: 0.68, 0.56, 0.59
manejando unos 140 procesos de apache ( muchos más en hora pico cerca de los 250 ) y aun tiene la mitad del procesador libre..
El load común antes de estos cambios era de más de 9
.

10:10pm up 36 days, 12:19, 1 user, load average: 0.68, 0.56, 0.59
203 processes: 193 sleeping, 10 running, 0 zombie, 0 stopped
CPU states: 15.9% user, 14.4% system, 11.1% nice, 58.3% idle
Mem: 506024K av, 468176K used, 37848K free, 0K shrd, 25916K buff
Swap: 1020116K av, 49596K used, 970520K free 195640K cached

. . . .total used free shared buffers cached
Mem: 494 455 38 0 23 181
-/+ buffers/cache: 250 243
Swap: 996 48 947

Adicionalmente una optimización del servidor mysql seria lo indicado….

El primer paso es generar un par de llaves, usaremos DSA debido a que es más segura que RSA. Si deseas ponerle una contraseña, la puedes poner, en caso contrario solo presiona enter. Una contraseña es recomendable por que forza al usuario a necesitar la contraseña de la llave. El problema es que si deseas la llave para realizar procedimientos automatizados la llave tiene que hacerse sin password por comodidad.( Normalmente mis llaves personales van sin contraseña )

—–comando—–
ssh-keygen -t dsa
—–comando—–

Esto crea dos archivos id_dsa y id_dsa.pub. Seria altamente recomendable que mantuvieras un respaldo de ambos archivos en caso de querer usar esta llave en varios servidores. La parte más importante es que guardes el archivo id_dsa en un lugar MUY seguro, si alguien más obtiene dicho archivo, podrá entrar a cualquier servidor con esa llave instalada. Ahora haz cat en el archivo pub y salva el texto, lo vamos a usar en el otro servidor.

—–comando—–
cat ~/.ssh/id_dsa.pub
—–comando—–

Ahora entra a el otro servidor como el usuario en donde quieres instalar la llave y haz lo siguiente:

—–comandos—–
mkdir ~/.ssh/
touch ~/.ssh/authorized_keys2
emacs ~/.ssh/authorized_keys2
—–comandos—–

Ahora pega los contenidos de id_dsa.pub ahi y salva el archivo. Ahora cambiaremos los permisos del archivo ( algunas versiones de SSH son muy pedantes al respecto de los permisos del archivo authorized_keys2 ).

—–comando—–
chmod 700 ~/.ssh/authorized_keys2
—–comando—–

Las llaves Ssh ahora deberian estar funcionando. Intenta entrar y revisa si funciona, si no es asi, intenta hacer un ssh -v user@host, la opción -v activará el modo en el cual verás pasos relevantes de la transaccion actual y puede ayudarte a diagnosticar el error.

**********************************************
**********************************************
Algunas cosas mas avanzadas que se pueden hacer con llaves ssh:

Activar login de root solo si el usuario usa llave ssh:

El permitir acceso a root solo con el uso de llaves ssh. Esta opción es muy valiosa ya que prevendrá que alguien intente entrar con procesos de login aleatorio y eventualmente obtener acceso al sistema y permitirá aún entrar como root. En un mundo ideal se configuraria el acceso solo usando llaves de ssh y permitiendo sólamente a un usuario capaz de hacer sudo en accesar. pero sé que esto no es algo práctico para muchas personas.Para permitir acceso a root usando solo llaves ssh se necesita editar el archivo sshd_config

—–comando—–
emacs /etc/ssh/sshd_config
—–comando—–

Busca donde dice “PermitRootLogin yes”, comentala con un #. Haz una nueva linea justo abajo que diga “PermitRootLogin without-password”. Salva y reinicia ssh.

—–comando—–
service sshd restart
—–comando—–

Despues de esto.. solo se puede entrar con root por ssh usando autorización por llaves.

**********************************************
**********************************************

Si quisiera usar llaves ssh con putty descarga puttygen.exe de http://the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe y ejecuta el programa. En las opciones selecciona DSA y luego “generate”. Una vez hecho verás una seccion con el texto que contiene la llave publica para colocarla en el archivo authorized_keys2 justo como arriba se describe.

**********************************************
**********************************************

Hay muchas cosas que se pueden hacer con ssh, como mover backups automaticamente o correr comandos en un servidor remoto desde otro pero eso es más de lo que explique esta vez. Hay mucha información en Google acerca de llaves ssh si es que necesitas más información o ideas de como usarlas más.