Tag Archives: servidores

La importancia de la actualización

Desde hace años, me vengo encontrando con sistemas instalados que hay que mantener o sobre los que hay que desarrollar, que son instalaciones de hace 5 ó 7 años. Estas instalaciones suelen ser máquinas con RedHat 9, RedHat EL 2, 3 ó 4, o Fedora Core 2 ó 3. En esos años RedHat estaba muy metido en el entorno empresarial y Fedora Core fue una respuesta libre (totalmente) a la desaparición de RedHat Desktop.

El caso es que la empresa y la comunidad que soportan ambas distribuciones (incluso distros comos OpenSuSE o SuSE, Mandriva y otras similares) les pasa que desarrollan versiones de forma bastante rápida (una o dos al año), con lo que, pasando 5 años, pueden haber salido unas 10 versiones posteriores del producto.

Esto genera problemas, sobre todo para la comunidad y la empresa que las mantiene, que deben de ir cerrando soporte de las antiguas, porque sino sería un caos el mantenimiento de 10 distros con versiones distintas de los códigos que se incluyen. A día de hoy, RedHat no suele mantener nada más que dos versiones, al última y su anterior, y Fedora Core, como mucho, da soporte a las 3 ó 4 últimas, con lo que, yendo actualmente por la versión 12, es lógico que el soporte a la versión 2 y 3 ha expirado hace bastante tiempo.

¿Qué pasa si hemos instalado un servidor web con estas distribuciones y queremos mantenerlo para nuestro correo, página web y otros menesteres?, pues que sino actualizamos, llegará el momento en el que haya vulnerabilidades en el código de nuestro servidor de correo, nuestro servidor web, o que queramos simplemente actualizar la versión del CMS que estamos usando y necesite una versión superior de Python, PHP o Ruby, o no tengamos forma de instalarla, a menos que vayamos tirando de compilación.

En Debian también pasa algo parecido. El ritmo de liberación de las distribuciones es más lento, con lo que da un tiempo mayor de permanencia de una distribución a su siguiente liberación. Pero el cambio es mucho mayor en este sentido, puesto que las versiones, cuando se cambian, son saltos bastante grandes y requiere de un mayor esfuerzo de adaptación.

¿Qué hacer?, básicamente, ir actualizando y mantenerse al tanto de cuando sale la siguiente liberación de la distribución que estamos usando y, sobretodo, planificar tiempos cada 5 ó 6 meses, para actualizar las distribuciones a sus versiones superiores, ya que así estaremos más protegidos de posibles vulnerabilidades.

Tener presente que si el cambio no se realiza, puntualmente, antes de que el soporte oficial a la distro que tenemos instalada expire, nos veremos en la situación de tener un sistema con agujeros de seguridad, que es propenso a fallos y sobre el que, cada día que pase, será más complicado instalar software nuevo.

La Regla de los Nueves

Esto es algo que aprendí, ahora hace ya unos 5 años, cuando comencé a instalar mi primer servicio de alta disponibilidad.

En un artículo sobre el tema, la alta disponibilidad, se decía que la disponibilidad de un servicio, servido únicamente por una máquina, normalmente es de un 90%, con lo que, a lo largo de un año (365 días) el servicio se ha mantenido en funcionamiento un máximo del 90%, aproximadamente, y ha tenido un tiempo de inactividad del 10% (más o menos unos 36 días).

Con sistemas de alta disponibilidad, es decir, teniendo más de una máquina siriviendo un servicio, la proporción se incrementa, pero siempre a razón de nueves. Es decir, con dos máquinas, tenemos una disponibilidad del 99%, con tres máquinas tenemos un 99,9%, con cuatro un 99,99% y así sucesivamente.

Como nota curiosa, hace poco leí que los sistemas desarrollados sobre Erlang/OTP tienen una alta disponibilidad de nueve nueves (99,9999999%), lo cual me parece algo increíble, pero totalmente cierto, ya que he probado la infraestructura y realmente es muy estable.

Sistemas de Mensajes Encolados (MQ)

Hace poco me he encontrado con un problema. Tengo un entramado de servidores y comunicaciones entre cada uno de ellos. Cada servidor puede notificar, ya sea vía SOAP, HTTP, XMPP o mediante cualquier otro protocolo, un evento o una información a otro servidor del entramado, con lo que cada servidor se configura de una forma específica, con una serie de nombres de dominio o IPs.

El problema viene al querer aplicar escalabilidad al proyecto. Cuando no solo hay un equipo implicado, sino que existen dos o tres, los cuales hay que configurar bajo ciertas circunstancias.

Lo primero que pensé, es que, si le puedo notificar a la red de que sucede un evento en concreto, ya sea a una sola máquina o conjunto definido de estas (pero para todos los equipos la misma configuración), facilitaría la puesta en producción. Con lo que me puse a buscar y encontré MQ, message queue.

El encolado de mensajes

La comunicación de los equipos informáticos se basa en mensajes, en eventos, que deben de poder transmitirse de unos a otros cuando sucedan (si es que se quiere tener la máxima fiabilidad en la información que se trata).

Una forma es comunicar directamente al implicado, lo cual resulta un poco tedioso si los implicados son muchos y muy distintos.

Otra forma es mediante un sistema JMS o un MQ, como RabbitMQ.

El encolado de mensajes es un sistema que permite que un elemento perteneciente a un sistema de información, pueda comunicar un estado, evento o mensaje informativo o imperativo a otro conjunto de elementos dentro del sistema, para que interactúe con él.

Por ejemplo, si tenemos un servidor web, una interfaz, que controla un conjunto de máquinas encargadas realizar llamadas salientes, rastrear páginas de la web para almacenar información para un buscador o similar, y la interfaz quiere enviar parámetros nuevos de configuración a estas, puede hacerlo mediante el envío de un mensaje generalizado a ese conjunto de máquinas, y estas máquinas recibirán el mensaje en el momento que lo soliciten.

Esta utilidad es igualmente buena para cuando una interfaz web, por ejemplo de un estudio fotográfico, carga imágenes desde la web, las retoca con algún tipo de efecto, ajuste, etc. y más adelante permite su descarga. El sistema web puede enviar el evento al sistema de retocado de que hay una imagen disponible, y cuando la imagen ya está disponible, el sistema de retocado puede enviar otro mensaje de vuelta diciendo que ya está.

Quizás esto último podría hacerse mejor con una base de datos, pero con el sistema de mensajería, se eliminan los datos en el momento que ya no se necesitan, mientras que con la base de datos, esos datos podrían permanecer ahí de forma indeterminada.

Conclusiones

Los sistemas de encolado de mensajes tienen su utilidad, sobre todo, en sistemas formados por varias máquinas, con roles bien definidos y en las que se quiere afinar lo que son las conexiones y comunicaciones entre las máquinas.

Escalado de Ruby on Rails

Después de liberar el primer proyecto escrito en Ruby on Rails, cuando lo pasamos a producción, nos dimos cuenta de que el sistema funcionaba realmente lento. En algunos casos, incluso, no respondía, con lo que buscamos información por internet y vimos:

Mongrel y Thin no son multi-hilo

Fue algo que nos sorprendió mucho, una aplicación servidora secuencial, que atiende las peticiones una a una y, en caso de que una petición se tarde un par de segundos (que las teníamos :-S ), el sistema se queda trabado durante todo ese tiempo.

Las soluciones posibles eran dos:

  • Phusion Passenger, también conocido como mod_rails, es un módulo para Apache que mantiene tantos hilos como peticiones se vayan gestionando, siempre con unos límites máximos y mínimos, tal y como apache suele hacerlo.
  • Ngnix + Thin, esta solución fue un poco más artesana, por decirlo de alguna forma, ya que consistía en configurar este servidor web como proxy inverso, para hacer el balanceo de peticiones entre todos los hilos de thin que se quieran cargar en el sistema. Descartamos en este punto a mongrel por comentarios que había leído en otros blogs.

Bien, por correr lo más posible, lanzamos tantos hilos como nos fue posible en la máquina que dedicamos al proyecto y, nos complació ver que podía aguantar hasta 40 hilos, sin que sus CPUs lo notasen apenas. Con lo que conseguimos un pool de 40 puertos dedicados a atender peticiones HTTP.

En otra máquina se configuró un proxy inverso. En el escenario de pruebas usamos nginx, aunque el tenerlo en la misma máquina y hacer pruebas masivas, nos dio como resultado que una cantidad importante de peticiones se perdían o transformaban en respuestas de tipo 500 por parte de nginx. Optamos entonces por un balanceador que tiene la compañía vía hardware, muy rápido y, a día de hoy el sistema web tira tan rápido y casi mejor que el que tenemos montado en PHP :-)

En el próximo artículo comentaré las configuraciones, arquitecturas y demás seguidas, sobre todo a nivel de nginx y thin, que es lo que realmente interesa.

MVCC: Control de Concurrencia para Múltiples Versiones de PostgreSQL

El sistema de base de datos PostgreSQL integra un sistema de control de concurrencia para múltiples versiones, en principio. Esto no es más que un sistema que se encarga de mantener copias sobre los datos de forma paralela, para acelerar el sistema de escritura de datos a disco duro, haciendo un control de concurrencia entre las distintas versiones que se van escribiendo.

El problema que intenta solucionar este sistema es el siguiente. Imagina que tenemos un sistema que hace múltiples escrituras y lecturas de una base de datos. No es difícil, seguro que conoces cientos de sistemas que lo hacen. Ahora, ten en cuenta que, los accesos a base de datos, depende para qué, realizan ciertos bloqueos, para asegurarse de que la información a modificar o a leer (incluso) no es modificada por nadie, hasta que termine su actividad.

En MySQL, por ejemplo, existen distintos tipos de bloqueos, muchos de ellos automáticos, que hacen el bloqueo de una tabla completa, o de ciertas partes específicas, al hacer una actividad de modificación, o un bloqueo compartido, para hacer actividades de lectura (solo bloquea en este caso a los que intentan escribir).

Pero en tema de índices, hay muchos SGBD que usan sistemas de índices que al actualizarse, se bloquean completamente, dejando, no solo las escrituras bloqueadas, sino también las lecturas, creando un lag de acceso a los datos.

Interbase fue la primera base de datos que eliminó la contención, los deadlocks y garantizaba transacciones ACID mediante el sistema MVCC. La idea es: no actualizar ni eliminar nunca una fila del disco. Si deseas actualizar, se agrega una nueva fila con la misma clave primaria, la cual oculta la antigua fila. Si deseas eliminar, agrega una nueva fila que etiqueta la clave primaria como eliminada, la cual oculta la antigua fila.

Las viejas filas no eran nunca actualizadas, así que no era necesario implementar ningún sistema de bloqueo y la contención (o espera) mágicamente desapareció.

El sistema, no obstante, tiene pequeños defectos: usa más espacio de disco y puede ser algo más lento a la hora de leer datos. La buena noticia es que los datos se pueden respaldar (realizarse un backup) en cualquier momento sin bloquear el sistema.

En MySQL, los tipos de tablas Falcon (a partir de la versión 6.0) e InnoDB (antes de la 6.0), implementan este sistema para las actualizaciones (updates) usando bloqueo a nivel de fila, lo cual puede causar un tiempo de espera para otros procesos (contención).

En PostgreSQL se usa el comando VACUUM para actualizar las base de datos, es decir, implementar las transacciones agregadas al final en lugar de a las que reemplazan y eliminar las tuplas marcadas para reclamar más espacio en disco. Esta operación demora, pero hace que la base de datos pase de un consumo alto de disco duro, al ajustado que debe de ser, antes de la próxima sesión crítica :-)

Hay otras bases de datos que también implementan Multiversion concurrency control, tal y como menciona la wikipedia, tales como:

  • Berkeley DB: que es una base de datos a nivel de fichero, como puede ser SQLite, pero sin uso del lenguaje SQL.
  • CouchDB: de la cual ya comenté algunas cosas en otro artículo.
  • Oracle 7: y superiores.
  • Microsoft SQL Server 2005: y superiores. El soporte es opcional, se pueden configurar los niveles de aislamiento (isolation) para poder usar MVCC o no.
  • MySQL: a través de InnoDB o Falcon, pero se usa nivel de bloqueo por fila, en lugar de snapshot.

Más información:

Debootstrap: probar sin ensuciar

Desde hace tiempo, llevo usando esta herramienta para generar jaulas de modo que pueda probar nuevos sistemas, servidores y/o configuraciones, sin necesidad de desconfigurar mi sistema actual.

El sistema se basa en tener una copia exacta y nueva de un sistema operativo basado en Debian GNU/Linux, que se instala en un directorio específico de nuestro árbol de directorios. El comando que genera la jaula, que tiene el nombre de debootstrap, se encarga de realizar la instalación del sistema a partir del directorio solicitado y con las fuentes solicitadas, es decir, si queremos instalar un woody, sarge, etch, lenny… o un gutsy, hardy, ibex… pues solo tenemos que indicarlo, con la URL de donde conseguir los paquetes y listo.

Por ejemplo, instalar en nuestro directorio /home/usuario/lenny una distribución lenny de Debian, sería hacer lo siguiente:

# debootstrap lenny /home/usuario/lenny http://ftp.rediris.es/debian

Esto tardará unos minutos hasta realizar la instalación completa, ya que se tiene que descargar los paquetes de internet, pero en el momento de finalizar, tendremos un sistema básico de lenny instalado en la ruta indicada.

Para poder usarlo, solo tendremos que hacer lo siguiente:

# mount -t proc proc /home/usuario/lenny/proc
# chroot /home/usuario/lenny

El hecho de montar el directorio proc es para poder tener acceso, desde la jaula, al kernel y poder lanzar servidores como apache, proftpd, postfix o similares.

Una vez dentro, podremos realizar las instalaciones y configuraciones que queramos realizar sin miedo de estar estropeando nuestra configuración normal.

PostgreSQL: configuración de acceso

Esto es algo que siempre me toca buscar en Internet, puesto que es algo que hago una vez cada tantos meses, y siempre se me olvida de cómo empezar, así que, para tener la chuleta a mano, he decidido escribir esta entrada que, además de servirme ahora, seguro que me servirá en el futuro para cuando configure más servidores de este tipo.

Aquí os dejo el enlace: PostgreSQL: Instalación, Configuración y Trucos.

SQL Server vía ODBC en Debian Etch

Casi a punto de asistir a la liberación de lenny (la versión 5.0 de Debian), seguimos viendo que con etch, aún, tenemos lo suficiente para tirar perfectamente, y sin agregar paquetes de backport.

En este caso, voy a explicar como instalar y usar SQL Server vía ODBC desde cualquier aplicación en GNU/Linux, como pueden ser programas Java, Perl, PHP, Ruby…

En principio, vamos a tirar de apt-get para instalar algunos programas:

apt-get install tdsodbc unixodbc libct3 libltdl3 odbcinst1debian1

Lo siguiente es crear el fichero /etc/odbcinst.ini, que debe de contener lo siguiente:

[FreeTDS]
Description     = TDS driver (Sybase/MS SQL)
Driver          = /usr/lib/odbc/libtdsodbc.so
Setup           = /usr/lib/odbc/libtdsS.so
CPTimeout       =
CPReuse         =

Ahora, para cada base de datos a la que queramos conectarnos, habrá que agregar un bloque de este tipo en el fichero /etc/odbc.ini:

[contactos]
Driver      = FreeTDS
Server      = 192.168.1.5
Database    = contactos
TDS_Version = 8.0
Port        = 1433

El nombre de la conexión es el que se situa entre los corchetes, y el que se usará para referenciar a esa conexión.

Para comprobar, podemos ejecutar el comando isql con los siguientes parámetros:

isql contactos usuario clave

Con esto, desde interfaces como DBI (Perl y Ruby), podemos usar DSN del tipo DBI:ODBC:contactos para acceder a esta conexión, siempre pensando que el usuario y la clave debe de insertarse en el comando de conexión.

Servidor de hora en GNU/Linux

En las redes internas de la mayoría de empresas, se sucede la necesidad, muchas veces, de tener sincronización horaria en las máquinas para mejorar el rendimiento y la calidad de los datos a almacenar, de cara  a anotaciones y lanzamiento de tareas programadas.

La sincronización horaria es completamente posible de llevar, simplemente, instalando un servidor de hora NTP dentro de nuestra red, para que nos haga de servidor de sincronización.

En España, generalmente, se suele usar hora.rediris.es como servidor de hora, puesto que es un sistema formado por varios servidores, algunos de ellos con el uso de relojes GPS.

Muchos sistemas ya tienen el servidor ntpd instalado. En otros habrá que hacer la instalación, ya sea del paquete con nombre: ntp, ntp-server, ntpd…

El archivo de configuración, normalmente: /etc/ntp.conf; debería de tener un contenido parecido a este:

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
 
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
 
server hora.rediris.es
 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
 
restrict 127.0.0.1
restrict ::1
 
restrict 192.168.123.0  mask  255.255.255.0 notrust
 
broadcast 192.168.123.255
disable auth
broadcastclient

Con esto, el servidor de hora recién instalado, servirá como repetidor para los equipos de la red interna. En caso de tener un solo equipo, en ese caso es mejor tomar el archivo de /etc/ntp.conf y modificarlo levemente para hacer que el sistema fucnione, y nada más.

Espero que os sirva de ayuda.

Asterisk: Configuración de Zapata

Este artículo ha pasado a formar parte de bosqueviejo.org, puede verlo en sus formatos html y pdf.