Argentina On Rails Hosting.new [:nginx, :mongrel_cluster, :mysql]

Hosting.new [:nginx, :mongrel_cluster, :mysql] - Parte 1/4

May 22nd, 2007

Hace algo más de dos meses decidimos comprar un buen equipo para dejar de usar hosting compartido (que le daba servicio a blog.onrails.com.ar y a varios sitios más), ya que nos estaba trayendo muchos problemas de estabilidad y performance, y ni hablar de algunos temas de compatibilidad. Por esta razón comenzamos a pensar cual era la mejor alternativa a la plataforma existente.

El stack

Opciones para correr aplicaciones Rails hay miles (bueh, no se si tanto). Nuestra idea no era proveer hosting, sino hacernos las cosas simples y no tener un techo de crecimiento demasiado establecido. Con esas premisas en mente optamos por la siguiente configuración:

Sistema Operativo: Debian Linux (etch)
FrontEnd: Nginx (el ruso que lo hizo la tiene atada)
AppServer: Mongrel (con su amigo mongrel_cluster)
DbServer: MySQL (confiable, performante, simple y amigable)

¿Por qué virtualizar?

El hardware que compramos no fue increiblemente de ultima generación (Pentium IV-HT), y había dos opciones (a la vista por lo menos): instalar todos los servicios en el mismo equipo o invertir en más servidores para poder separarlos y no tener problemas de escalabilidad/isolación/seguridad. Algo había leido sobre Xen, pero nunca me había metido lo suficiente (al menos sobre linux), entonces hablamos con Pedro y decidimos que la movida más interesante era usar xen para generar máquinas virtuales en un sólo servidor y así poder atacar los problemas enumerados anteriormente. Xen básicamente te permite ejecutar varios sistemas operativos en un mismo equipo, permitiendole al host (Dom0) administrar los recursos de cada uno de los guests (DomU). No requiere nada sofisticado y no consume demasiados recursos. No voy a decir que sea simple, pero no es rocket science. No voy a ahondar en detalles porque no soy un especialista en Paravirtualización y no quiero hablar sin saber, pero de todas las tecnologías de virtualización que analicé esta fue la que mejor se adaptó a nuestras necesidades actuales y la que menor impacto tenía a nivel performance. Solo se lleva un 3% de la CPU.

¿Cómo seguimos?

En los siguientes artículos de la serie iré relatando cada uno de los procesos de configuración de los jugadores de este partido. Todos tuvieron sus cositas y vale la pena comentarlo (creo yo). ;) Ojo, no va a ser una guía exhaustiva, sino una lista de tips a tener en cuenta al embarcarse en esta tarea.