Es muy satisfactorio cuando tus prejuicios de viejo carcamal se confirman. Lo malo es que a veces eres tú mismo el sujeto de pruebas, y tus quejas te afectan directamente.

Todo empezó cuando un compañero de trabajo me dijo que en kemsirve.es había VPSs (servidores virtuales privados) por 5€ al mes. Ahora mismo, mi otro weblog y una buena parte de mi correo están en un VPS de Gandi, por el que pago unos 14€ al mes. Sus características son:

  • Tecnología Xen
  • 256MB de RAM
  • 3GB de disco para el sistema
  • 5GB de disco adicionales
  • 1/12 parte de la CPU del host
Aparte, la E/S también está limitada, y se nota que cuando haces algo que requiera leer o escribir en disco duro (un "rpm -qa", por ejemplo) le cuesta un poco. No llega a ser molesto, pero tarda más que en un equipo normal.

En kemsirve.es hay VPSs por 5€, con estas características:

  • 512MB de RAM
  • 25GB de disco
  • "1 vCPU" (sea lo que sea eso)
En resumen: doble de potencia, casi una tercera parte del precio. Irresistible. Tras varias semanas de darle vueltas (soy así de decidido), compré un VPS por tres meses para probarlo y, en algún momento, pasar mis cosas ahí.

Oro parece, OpenVZ es

Lo primero que vi al entrar fue que no tenía un disco duro virtual, como en Xen, sino un raíz de 25GB del sistema de ficheros "simfs". Buscando un poco vi que eso era OpenVZ. No lo había usado nunca (siempre me ha parecido un chroot con esteroides, no virtualización de verdad), pero por 5€ al mes estaba dispuesto a aparcar mis prejuicios. Y encerrarlos en un garaje cubiertos por una lona, si hacía falta.

También descubrí que sólo tenía 128MB de swap. En mi VPS de Gandi podía configurar el swap yo mismo: te dan un disco duro virtual, y tú haces con él lo que quieras. Puse LVM y dediqué un volumen de 512MB para swap. En OpenVZ no hay nada de eso: tienes 128MB de swap, y punto. ¿Y qué pasa cuando agotas la memoria y el swap? (que no es muy difícil, si quieres montar algo más que un servidor web chorras) Ahí empieza la diversión.

Primero os voy a describir el escenario, para que os hagáis una idea de la situación. Ahora mismo, los servicios que ejecuto en mi VPS son:

  • apache, con PHP, para Wordpress y Drupal (el viejo weblog, en modo "read-only")
  • MySQL, para el weblog y la BD del antispam
  • amavis, el antispam
  • Bind, para mis dominios y un par más
  • Postfix y Dovecot, para el correo

Con esta configuración, en el VPS de Gandi tenía regularmente unos 80-100MB de swap ocupados, y unos 50-60MB de RAM libre. Lo suficiente para que no notara retrasos al recibir correo ni al cargar mi página web. Si había un pico (si mi weblog pasaba de las 10 visitas diarias habituales, por ejemplo), todavía me quedaba swap de sobra.

Los procesos que más memoria ocupan son httpd, mysqld, named y amavisd. La configuración de MySQL no está muy optimizada, pero las de apache y amavis son muy espartanas: muy pocos procesos, pocas conexiones simultáneas, etc. Lo justito, vaya.

Con esta configuación he lanzado un par de "apachebench" con concurrencia de 20 y unos cuántos miles de consultas y nunca he tenido problemas. La página se vuelve lenta y todo se queda un poco frito durante la prueba, pero al acabar se recupera tan grácilmente como un octogenario con artrosis después de una caída.

Pero cuando haces esto contra el VPS con OpenVZ, los 512MB de RAM apenas llegan para todos los procesos de httpd que se lanzan; como no llega la RAM, se empieza a usar el swap; y en apenas un par de minutos, también se ha acabado el swap. Entonces el terrible "OOM killer" del kernel aparece, y siega con su guadaña procesos a diestro y siniestro. El primero en caer es amavisd, uno de los que más RAM ocupan. Si aprietas un poco más, luego cae mysqld. También named puede verse afectado, según cómo coincida. En resumen: masacre, destrucción total, apocalipsis, armaggedon, ragnarok. Mal rollo.

La solución más fácil es limitar de forma muy severa los procesos de apache, dejando sólo 10 simultáneos. Así siempre hay unos 60MB libres de swap, y otros tantos de RAM. Eso sí, el benchmark tarda muchísimo más, porque apache tiene que serializar todas las consultas que no puede atender de forma concurrente.

Aparte de eso, he instalado monit. No había usado nunca este programa, y ha sido una sorpresa muy agradable. Aparte de monitorizar los procesos, puede reiniciarlos cuando fallan. Tiene una sintaxis muy "human friendly", muy fácil de entender. Probé varios "stress tests" con monit instalado, antes de limitar los procesos de apache, y reinició correctamente todos los procesos que el OOM killer se había cargado.

Con monit y los límites de apache, pensé que podía sobrevivir sin miedo a que mitad de los procesos del sistema sufrieran una muerte horrible en cuanto la memoria estuviera un poco apretada. Pero OpenVZ tiene otras restricciones que todavía no había encontrado.

¿VPN? ¿Qué VPN?

Tengo una VPN con openvpn entre mi equipo de casa (con IP dinámica) y mi VPS de Gandi. Para entrar al VPS, incluso desde casa, me conecto por ssh; pero uso la VPN para hacer backup o para saltar desde cualquier sitio al VPS y luego a mi ordenador.

El kernel de OpenVZ no tiene soporte para módulos. Es un kernel "capado", más seguro, en el que no puedes ni cargarlos ni descargarlos. Eso quiere decir que, si no hay soporte para algo, no hay posibilidad de añadirlo de forma dinámica. Soporte para algo como, por ejemplo, los dispositivos TUN/TAP, que hacen falta para openvpn.

Pregunté al soporte de OVH si tenía que hacer algo especial o era una limitación del VPS, y me dijeron que era lo último. Que si quería, podía usar PPTP (la VPN que viene de serie con Windows). Pero PPTP está más pensado para "road warriors", gente que se conecta esporádicamente a un concentrador VPN para acceder a la red de su trabajo, no para una conexión estable y permanente. Así que me fui a la siguiente opción: IPSec, con openswan.

¡Ingenuo de mí! Ni de coña, tampoco había soporte para IPSec. Precisamente estaba usando openvpn porque apenas necesita soporte en el kernel, es todo en espacio de usuario. IPSec necesita soporte en el kernel de bastantes cosas, pero qué narices, tenía que probarlo.

Poco después, buscando en Internet, encontré un foro en el que un empleado de OVH reconocía que no se permitía ningún tipo de VPN "para evitar abusos". He estado buscando alguna opción que me valga para lo mismo desde entonces, pero en el fondo me duele tener que renunciar a una VPN sólo porque OVH tiene una política restrictiva respecto a lo que sus usuarios pueden hacer con sus VPSs. El precio es muy atractivo, pero si es lo único que pueden ofrecer, no es buena idea atarme a ellos.

Conclusión

No me gusta que me limiten arbitrariamente, como si fuera un niño pequeño. Y no me gusta OpenVZ. Por lo poco que he visto, son demasiadas cosas extrañas: el swap limitado, el espacio en disco no particionable, la IP 127.0.0.1 en el dispositivo venet0 (el equivalente a eth0), la falta de soporte en el kernel para cualquier cosa ... Si tengo un VPS es por cacharrear, por probar cosas, y con OpenVZ no podría. Con Xen tampoco puedo probar de todo, pero sí un poco más.

Así que dejaré que expire el VPS, me olvidaré de OVH y buscaré mi Shangri-La: un sitio con VPSs de tecnología Xen y precio más atractivo que el de Gandi. Si puede ser, en Europa, por eso de la proximidad geográfica.

Hoy mismo he encontrado algo que podría ser lo que busco: una oferta en providerservice.net por 1.9€ al mes (si se suscribe por 6 meses y antes del 30 de septiembre), con Xen, 512MB de RAM y 10GB de disco. Tiene un límite de tráfico de 500GB al mes, pero creo que no será un problema.

Seguiré informando por aquí. Estén atentos a sus pantallas.