Ser Libre

Una buena práctica en la administración de servidores es aplicar control de versiones para los archivos de configuración y otros referidos al funcionamiento del sistema operativo, de manera similar a lo que se hace con el código de las aplicaciones, aunque con ciertas características especiales.

Se puede usar cualquier sistema de control de versiones: CVS, Subversion, Git, etc. pero para éste caso específico voy a usar Bazaar , primero porque cumple con los requerimientos y segundo porque es muy fácil de usar.

Si bien la mayoría de los archivos de configuración se encuentran en el directorio /etc, hay que considerar otros directorios: tareas cron, scripts de sistema, etc. También podría ser necesario tener un listado de permisos de directorios importantes o listado de paquetes instalados. Como se ve, los archivos están distribuidos por todos lados así que el versionado se debe hacer a nivel de la raíz del sistema operativo y así conservar la misma estructura. Ésto es muy fácil:

bzr init /

Con este comando, ya tenemos un repositorio armado en nuestro servidor y además tenemos la facilidad de que si queremos eliminarlo, solo hay que borrar el directorio .bzr que está en la raíz del S.O.

Una vez hecho ésto procedemos a agregar los archivos o directorios que queremos versionar. Por ejemplo:

bzr ignore etc/httpd/logs
bzr add /etc/httpd
bzr commit /etc/httpd -m "estructura inicial configuración httpd"

bzr ignore indica que se va a ignorar el directorio logs (con ignore siempre hay que usar rutas relativas), luego se agrega y se hace commit del directorio /etc/httpd . Es una buena práctica indicar un mensaje coherente con -m , podría ser de utilidad cuando no nos acordemos para qué añadimos “esa opción” el año pasado.

Ahora, toda está información probará ser muy útil, pero aún sigue almacenada en el mismo servidor. Podemos también trasladarla a un repositorio central usando:

bzr push sftp://config@servidorcentral/~/servidor01

Lo que hace push es crear una nueva rama del repositorio pero en este caso lo hará en un servidor central dentro de un directorio con nombre servidor01. Para que esto funcione necesitaremos antes haber creado un usuario config. De esta manera en el servidor central se arma una estructura con las configuraciones de cada uno de los servidores versionados. Hay que tomar en cuenta que cuando se realiza un bzr push remotamente, no se copia la estructura si no la metadata, es decir el directorio .bzr . Pero la estructura es muy fácil de recrear con:

bzr checkout

Es decir que, desde el servidor central, se podrá revisar la configuración del resto de servidores actual y pasada. Eso sí, hay que mantener la costumbre de hacer los commits después de hacer las configuraciones necesarias y los push una vez que se está satisfecho con el resultado.

Lo voy a poner bien claro: si están tratando de encontrar una definición correcta de “Cloud Computing”, están perdiendo su tiempo. Es un concepto tan ambiguo y difuso que nadie se pone de acuerdo en lo que es y no es. Mejor que eso: investigar un poco más sobre las tecnologías asociadas y los proveedores que ofrecen ese tipo de servicios.

Ahora volvemos a nuestra programación habitual.

Una de las cosas que me encanta de Ganglia es la facilidad para agregar métricas con el comando gmetric, las cuales posteriormente podamos visualizar en la interface web. Con un simple script en bash (en realidad en cualquier lenguaje) podemos generar la información necesaria para gmetric.

Por ejemplo, en un servidor web nos interesa conocer la cantidad de conexiones que se realizan ya sea a apache, lighttpd, nginx, etc. Como ejemplo para esta ocasión usaré lighty .

Lo primero que tenemos que hacer es habilitar la página de status de lighty a través del modulo mod_status . Para esto lo agregamos en la sección de módulos:

server.modules              = (
#                              otros modulos
                               "mod_status",
#                              más modulos
)

Ahora, por seguridad no queremos que esta página esté disponible para todo el mundo y en este caso en específico solo queremos que sea leída por nuestro script. Por lo tanto habilitaremos la url de status sólo para ser accesible desde el localhost:

$HTTP["remoteip"] == "127.0.0.1" {
  status.status-url = "/server-status"
}

Podríamos añadirle más opciones de seguridad pero con esto será suficiente. La página de status que se genera está en código HTML pero si queremos una versión en texto podemos acceder agregando ?auto a la url de status que definimos arriba.

Entonces para que nuestro script acceda a la información de status y guardarla en un archivo deberíamos usar algo cómo:

wget -q -O - http://127.0.0.1/server-status?auto > /tmp/status

El archivo temporal tendrá una estructura similar a ésta:

Total Accesses: 2308494998
Total kBytes: 95387409298
Uptime: 13293149
BusyServers: 516
IdleServers: 1532

Lo que nos interesa como métricas son los Busy Servers y los Idle Servers. No hay que confundirse con los nombres, recordemos que lighty no lanza “servidores” como Apache, el nombre es solo por compatibilidad. En este caso los “Busy Servers” representan la cantidad de conexiones activas en el momento. Así podemos parsear nuestro archivo y agregarlo como una métrica de ganglia a través de gmetric:

gmetric --name lighttpd_busy_servers --value `grep BusyServers /tmp/status | cut -d " " -f 2` --type float --units "Busy Servers"

Lo que hemos hecho es obtener el valor de BusyServers y agregarlo como una métrica tipo float de nombre lighttpd_busy_servers y cuya unidad es “Busy Servers” . Lo único que nos faltaría es crear una tarea vía cron para que nuestro script se ejecute cada cierto tiempo. Ganglia se encarga del resto y nos hará una bonita gráfica.

Dejo disponible el script para quien esté interesado en usarlo: ganglia_lighttpd.sh

Los que hemos trabajado alguna vez con Rackspace , reconocemos la diferencia entre su servicio y el resto de proveedores de hosting y en general con otras compañías, gracias a su “fanatical support”, que no es otra cosa que una dedicada orientación de servicio al cliente.

Pero detrás de su “fanatical support” hay un personal técnico muy capacitado que trabaja en soluciones de acuerdo a las necesidades del cliente. Por ejemplo, los servidores dedicados en Red Hat Linux, contaban con un sistema de actualización de paquetes que incluía repositorios propios de Rackspace. Así, si el cliente necesitaba una versión más actual de PHP que no estaba dentro de los repositorios oficiales de RedHat podía solicitar que Rackspace lo instale.

La buena noticia es que Rackspace finalmente ha liberado este repositorio al público en general, con lo cual todos los usuarios de servidores Red Hat o CentOS tendremos acceso a paquetes de python 2.6, php 5.3, mysql 5.1, etc. con los módulos y dependencias necesarias para que puedan trabajar de una manera estable sin tener que compilar nosotros mismos o recurrir a repositorios en los cuales no se puede tener total confianza.

Lo hecho por Rackspace le da un gran empuje al uso de servidores Red Hat y CentOS ya que la no disponibilidad de “versiones nuevas y suficientemente estable” de software tan importante como php o python les estaba haciendo perder la batalla frente a los servidores Ubuntu, que cuentan con una mayor disponibilidad de software.

Si bien Drupal tiene el módulo Devel para hacer profiling a full, también se pueden hacer algunas cosas a mano usando una variable algo escondida en Drupal: $dev_query . Al activarla todas las consultas hechas a través de db_query serán almacenadas en un array ($queries) junto con el tiempo que duró la consulta.

Supongamos que queremos hacer profile de un pedazo de código en Drupal. Al inicio de éste llamamos a una funcion profile_start que active $dev_query y que comience a medir el tiempo que toma en ejecutarse el código.

function profile_start()
{ 
    variable_set('dev_query',1);
     $start = microtime();
}

También podemos usar getrusage() , que nos da muchos más detalles. Internamente db_query() también usa microtime() . Al final del código le diremos que el profiling se detenga con algo cómo:

function profile_stop()
{ 
    $end = microtime();
    global $queries;
    // se procesa la información almacenada por db_query()
    variable_set('dev_query',0);    
}

Hago notar que éste código no es funcional, pero al menos puede dar una buena idea de lo que se necesita hacer. Sería recomendable guardar los resultados obtenidos en una base de datos para procesarlo como queramos. Para que ésto no afecte nuestros resultados ni el rendimiento de nuestra aplicación podemos usar INSERT DELAYED de MySQL, de tal manera que el insert de los resultados se ejecuta en el background y se nos regresa inmediatamente dónde estábamos.

Algunas ideas más para hacer profiling de MySQL en PHP las pueden encontrar en el Capítulo 2 del libro High Performance MySQL (segunda edición): Finding Bottlenecks: Benchmarking and Profiling.

Hoy noté que cuando uno abría los enlaces en twitter no cargaba directamente el enlace sino que aparecía algo como http://twitter.com/link_click_count y luego recién se redireccionaba. Parece que Twitter está probando algún sistema de tracking de enlaces cuyas estadísticas seguramente incorporará en alguna futura versión PRO. Ya lo habían visto otros hace unos días también .

Lo que me hizo levantar la ceja es el hecho de que sí ya usamos servicios de acortadores de URL que extraen sus propias estadísticas antes de enviarnos al destino final, ¿cuánto afecta este tiempo adicional a nuestra navegación?.

En Royal Pingdom ya habían medido el overhead que añaden a la navegación los distintos acortadores. Ahora lo que faltaba era calcular el overhead de esta nueva implementación de Twitter. Para ésto usaremos Hammerhead , una herramienta creada por Steve Souders para medir el tiempo de carga de distintos sitios varias veces. Así que para el experimento consideraremos medir los tiempos de Google.com, Google.com acortado por Bit.ly y Google.com acortado por Bit.ly y pasado por el link_click_count. Los resultados son más que interesantes. Éstos son los tiempos en promedio, luego de 10 vueltas:

• google.com : 854 ms
• google.com + bit.ly : 1044 ms
• google.com + bit.ly + link_click_count : 1943 ms

Nota: Las pruebas se hacen desde una conexión internet bastante decente en Perú, los tiempos son evidentemente más altos que en USA pero lo que importan son las diferencias entre los tiempos. Ustedes mismos pueden hacer sus pruebas usando Hammerhead.

Vemos que el tiempo añadido por bit.ly (190 ms) se corresponde con los 260 ms que había encontrado Pingdom, lo cual le añade un poco más de veracidad a los resultados. Pero lo más sorprendente es que el link_click_count de Twitter le añade 900 ms a la carga de bit.ly ocasionando un delay de 1089 ms. Lo cual no es raro considerando que Twitter no es precisamente el sitio más rápido del planeta.

En resumen, cada vez que uno hace click en un enlace vía twitter, en promedio sufre 1 segundo de retraso para llegar a la información. A simple vista parece una nada, pero en internet los segundos son oro, si no recuerden una de las conclusiones más interesantes de la conferencia Velocity 09: retrasos de milisegundos representan pérdidas de ingresos y usuarios para un sitio web (estadísticas provenientes de Google, Microsoft, AOL, etc.) , mientras que la gente de Facebook dice que: Cada Milisegundo cuenta

¿Seguirá Twitter con esta implementación?, ¿finalmente se animarán a usar un servicio propio para acortar URL’s?, literalmente nos están haciendo perder 1 segundo en la vida cada vez que hacemos click en uno de sus enlaces.

El año pasado Jeff Attwood y Joel Spolsky le dieron vida a StackOverflow, un sitio de preguntas y respuestas relacionados con la programación. Bajo la misma estructura, pero con temas relacionadas con la administración de sistemas, surge en el 2009: ServerFault , en el cual estoy registrado hace unos 3 meses.

A mi personalmente el contestar preguntas en ServerFault me ha servido para reforzar algunos conocimientos y al mismo tiempo aprender otras cosas relacionadas con temas con los cuales tengo que trabajar a diario. A veces cuando la cabeza no da para más, hacer una pregunta sirve para ver las cosas desde la perspectiva de otros. Y finalmente, siempre hay algunas preguntas “entretenidas” como: The Coolest Server Names o How do you become a sysadmin , que suelen arrancar más de una sonrisa.

Con el tiempo, ServerFault se terminará convirtiendo en una gran base de conocimiento en la administración de redes, servidores windows o linux, y contribuir a su crecimiento es una tarea entretenida y satisfactoria, sobre todo cuando alguien acepta tu respuesta. Se ha convertido en mi sitio web favorito y ahí me encuentran .

Interesante que Peru21 haya realizado un informe sobre el WiFi a propósito de la reciente implementación del llamado “internet gratuito” en la Municipalidad de Carmen de la Legua. Sin embargo creo que hay algunos detalles que hay que aclarar:

• En el gráfico ¿Cómo funciona el Wi-Fi? hay varios errores: las empresas proveedoras pueden llegar hasta el punto de acceso a través de varias tecnologías no sólo línea telefónica + módem ADSL, existen los cable modems, la fibra óptica, redes inalámbricas, etc. El WiFi además no está limitado a distancias cortas, se puede usar la misma tecnología para conseguir enlaces de mayor distancia.

• El WiFi no es el único tipo de tecnología inalámbrica que existe, aunque sea la más popular y más accesible. Éstas características son también su principal problema ya que el bajo costo de los equipos ocasiona que el espectro de frecuencias que usa el WiFi se vea inundado por señales ya sea domésticas o de proveedores (formales e informales). Por eso actualmente si se va a considerar levantar una red inalámbrica a gran escala que pueda ser estable se prefiere otras tecnologías (wimax, canopy, etc.)

• WiFi no es “wireless fidelity” …

• El acceso a internet está basado en redes de comunicaciones, nada garantiza que en una emergencia, éstas no vayan a fallar tan igual o peor que los servicios telefónicos. Durante el terremoto de Pisco, se produjo una falla en la fibra óptica de Telefónica que ocasionó que parte del tráfico nacional se fuera por un enlace redundante de menor capacidad. Nada es perfecto.

• No existe el llamado “internet gratuito” , alguien tiene que hacerse responsable del costo de los equipos necesarios para cubrir con señal inalámbrica un distrito, del ancho de banda total que se proveerá y del soporte de la red.

• No hay muchos detalles acerca de lo que se ha hecho en Carmen de la Legua: ¿es realmente wifi o se usa otra tecnología?, ¿cómo está estructurada la red?, ¿cuánto es el ancho de banda hacia internet contratado?, ¿cuánto es el ancho de banda que se provee al usuario final?, ¿qué empresas proveen los servicios de internet, los equipos y el soporte?. Son demasiadas preguntas para que queden en el aire, sería interesante conocer las respuestas.

• Siempre existe también el latente problema del mal uso que se le pueda dar a un servicio gratuito. ¿cómo se controla que yo un día me siente y me ponga a bajar mis torrents? o ¿que la gente empieze a quejarse porque el servicio está continuamente saturado?. Hay dos vías: o se aumenta el ancho de banda o se controla, ambas implican mayores gastos.

• Las redes WiFi gratuitas/municipales no han sido del todo exitosas. Y me pregunto si las que lo han sido hasta qué punto son realmente gratuitas sin implicar un aumento contínuo de los gastos manteniendo una buena calidad del servicio. Me gustaría saber de un caso de éxito, y ojalá que Carmen de la Legua pueda serlo pero me quedan demasiadas dudas.

Finalmente, nunca he sido muy amigo de estos servicios gratuitos, deberíamos fijarnos más en conseguir que se abaraten los costos del ancho de banda, exigir mejor calidad de servicio a los proveedores y nosotros como usuarios tener una mejor cultura sobre cómo acceder a estos servicios.

Hace ya algunos meses que SismoPeru viene funcionando en Twitter, reportando los últimos sismos producidos en el Perú tan pronto como la web del Instituto Geofísico del Perú se actualice con la información. La aplicación la desarrollé con Google AppEngine a modo de experimento. Lo que hace es conectarse al reporte web de Último Sismo del IGP, obtener los datos, guardar la información relevante en una BD y enviar el mensaje usando la API de Twitter. Además en el sitio web de SismoPeru hay un mapita de Google Maps con las ubicaciones de los 5 sismos más recientes.

Es una experiencia interesante, AppEngine es un framework que tiene cosas buenas pero por otros lados presenta limitaciones que hay que saber superar. Otro problema ha sido unir dos servicios que no se caracterizan por su confiabilidad: Twitter (que sigue teniendo sus hipos) y la web del IGP que sufre mucho con cada sismo. Espero que SismoPeru le alivie un poco la carga.

Lo que si es cierto es que Twitter se presenta como una buena oportunidad para desarrollar ideas simples como ésta, que puedan llegar a mucha gente y ser útiles. Ya lo hizo primero Bomberos y seguro que vendrán más cosas.

Y se les gustó como quedó el aspecto visual de la web de SismoPeru, hay que darle las gracias a Mariella quien sabe más que yo de esas cosas y además me dió varias ideas (y quejas ¬¬) sobre SismoPeru.

Como dije en la charla del Barcamp, la gente a seguir en temas de escalabilidad son los ingenieros de Flickr. Dos de ellos inspiraron parte de la presentación de aquel día: Cal Henderson y John Allspaw.

John Allspaw ha publicado recientemente The Art of Capacity Planning en el cual se destaca mucha información sobre su experiencia en Flickr. El libro es muy bueno, aunque se me hizo muy corto, bien se puede complementar con su blog Kitchen Soap . “Measurement” y “Predicting Trends” son los capítulos más completos, llenos de ejemplos y que demuestran lo importante que son las métricas y cómo se deben aplicar éstas para un correcto planeamiento de la capacidad de nuestros sistemas.

Es un libro práctico, no se detiene en fórmulas sino más bien aplica mucha lógica y eso me gusta. Una idea importante: dimensionar no significa optimizar, si en el proceso encontramos cosas raras debemos medirlas también y planificar en base a lo bueno, lo malo y lo feo, ya luego nosotros o alguien más se encargará de resolver el bug o el problema.

Si están en el tema, leánlo y ¡midan todo lo que puedan!