La sorpresa ha sido cuando he recibido la siguiente respuesta por parte del soporte:

If we were to offer you the PS service 150/150 for free would you be
willing to stay on this PS server?

Ni que decir tiene que he dicho que si No es un gran VPS porque 150Mhz y 150Mb no es gran cosa, pero es mejor que nada, y sobre todo que eso antes me costaba en esta configuración $15 mensuales.

A mi entender es una política inteligente por parte de Dreamhost, porque probablemente mi perfil es de poweruser para mover mis webs al pool de usuarios compartidos con las implicaciones que eso tiene, y que de esta forma siempre puedo volver a pagar más al reconfigurar el VPS con más recursos.

Estoy absolutamente convencido de que serán de utilidad para muchos poseedores de un Dreamhost PS por el simple motivo de que se van a ahorrar dinero desde el primer momento.

Lo que me ha llevado a lanzarlo este proyecto son los buenos resultados de mis scripts que he comentado en éste y este otro artículo, y el hecho de tener más ideas interesantes para este sector.

Ya veremos como acaba, esperemos que dure más de 3 meses

Una de estas ideas era poner solución al típico problema de recursos, y es que en principio tanto la CPU como memoria asignada no se dimensionan a la carga real, sino a lo que el propietario estime que es necesario.

En este contexto lo típico que puede pasar es que pagues mucho para dar un buen servicio puntualmente cuando tienes mucho tráfico y el resto del tiempo estés tirando el dinero porque el servidor va sobrado. O todo lo contrario, que vayas justo de recursos para ahorrar dinero y cada vez que surja un incremento de las visitas, se vengan abajo todas las webs porque no hay memoria disponible.

La operación de reajuste de CPU y memoria es totalmente manual y a través del panel de Dreamhost.

La solución ha sido otro script que he me programado que calcula de forma dinámica la memoria y recursos necesarios cada 5 minutos. De forma que si sobran recursos, se conecta al panel y los baja, y al revés cuando el servidor virtual empieza a quedarse sin memoria y swapear, se conecta y los aumenta.

En un par de días que lleva funcionando ya me he ahorrado unos buenos dólares y encima cuando me ha hecho falta más memoria (para aguantar algún pico) he dado un buen servicio sin que mis usuarios notaran nada.

La cuestión es la forma más rápida de arreglarlo es reiniciando el PS, y ésto solo se puede hacer manualmente desde el panel de control.

Como no puedo estar todo el día comprobando el estado de mi PS, ni tampoco voy a duplicar lo que pago por él, abrí un ticket con el soporte para ver si existía la posibilidad de automatizarlo:

Hi,

Is there any chance I could automate reboots on my Dreamhost PS?

For example, if the number of zombie process is above 5 -> reboot PS

The hard way it’s coding the Perl LWP script that logs in this panel and does the same thing at your form, but that’s too crappy and I’d prefer to not take that path

Best regards.

Antonio.

y la respuesta:

Hello Antonio,

> Is there any chance I could automate reboots on my Dreamhost PS?

Sorry! We currently do not have an option to easily reboot your Dreamhost
PS via the console. You will need to (unfortunately) write the script the
access the panel in order to setup this automated reboot process.

If we add anything in the near future I will be glad to let you know, but
right now there is no easy method to automate these reboots.

Thanks!

Pues ni corto ni perezoso como dice el dicho, en menos de 30 minutos me hice el script en Perl que hace exactamente eso

perl vpsreboot.pl
13:23:04: Logging at panel…
13:23:09: Logged in succesfully!
13:23:09: Requesting reboot of xxxxxx PS …
13:23:11: Reboot pending!

El script una vez ejecutado solicita el reinicio, no tienen ningún tipo de lógica para decidir si es necesario reiniciar o no (de momento).

Se me ocurren muchas mejoras como por ejemplo:

• Enviar un email cada vez que se solicite un reboot
• Añadir un delay entre solicitud y solicitud para evitar que sea invocado por error múltiples veces.
• Funcionalidad de monitorización de URLs o puertos del propio PS, y si después N errores acumulados ejecutar reboot del PS
• Recoger otras informaciones del propio panel y enviarlas por email o publicarlas en otra web. Por ejemplo las gráficas de uso de CPU y memoria (https://panel.dreamhost.com/index.cgi?command=png&machine=PSNAME&period=1+day y https://panel.dreamhost.com/index.cgi?command=png&machine=PSNAME&period=1+month)

Josh Jones, con su estilo personal característico lleno de muy buen humor y de imagénes muy bien escogidas – y que dicen mucho – relata ambos hechos que si bien tienen un trasfondo muy serio al implicar incluso a abogados de ambas partes, hacen que la lectura sea muy divertida quitando mucho hierro al asunto.

• The Gloves are Off. Caso de un supuesto non-soliciting entre Dreamhost y LunarPages, otro hoster.
• Robbing Your Customers. Explicación de las técnicas sucias empleadas por el hoster anterior (Lunarpages) y otras para robar clientes.

Evidentemente, para ser totalmente imparcial habría que escuchar que tienen que decir los del “bando contrario”, pero lo cierto es que tampoco me interesa mucho visto los hechos y con haberme reido un rato ya es bastante inversión de tiempo por hoy.

Por último, no puedo evitar reproducir la imagen del segundo artículo que me ha parecido buenísima:

Los artículos están en un inglés americano algo durillo de coger en algunas ocasiones por las expresiones que usan, pero son muy buenos y además suelen estar muy bien redactados y acompañados de imágenes muy bien escogidas. Además, siempre con muy buen humor, lo que los hace muy entretenidos.

Destacaré dos artículos (del año pasado) con los que estoy absolutamente de acuerdo con lo que comentan:

• Web Hosting’s Dirty Laundry. Análisis del mercado de todas esas empresas y webs que hacen reviews de quienes son los mejores hosters y supuestamente con una total imparcialidad. En el artículo incluso relatan una experiencia real con una de estas empresas.
• The Truth About Overselling!. Dreamhost ha sido criticado por muchos sectores de supuestos usuarios descontentos de que han sobrevendido como posesos y que por eso supuestamente funcionan tan mal. En este artículo explican lo que es overselling y cuál es la realidad detrás del escenario de una empresa de hosting (y cualquier empresa en muchos sentidos).

La evolución natural de cualquier arquitectura web es la de la distribución de carga en los frontales, esto es, en los servidores web, añades tantos servidores web como sean necesarios y así se reduce considerable la carga.

Está claro que este tipo de soluciones no son para los de bajo de presupuesto, pero hay una forma de emular este comportamiento conociendo como funcionan la arquitectura de hosting de Dreamhost.

Dreamhost usa clusters de webservers, con el fin de mejorar la disponibilidad del servicio (supongo). Hasta 3 nodos he visto yo en mi cuenta.

Cuando damos de alta un dominio nos asigna a uno de estos webservers. El objetivo es conseguir que nuestra web se vea por uno ó más webservers.

Para ello el método que he usado es el siguiente:

• Crear un subdominio del dominio principal. Por ejemplo www2.miweb.com y con directorio www2.miweb.com
• En gestión de dominios, seleccionar el enlace DNS del dominio principal. De esta forma vemos que IP se le ha asignado a www2.miweb.com. En mis pruebas siempre se le asignaba una IP distinta que correspondía a uno de los webservers del cluster.

Ahora se pueden adoptar dos vías, o bien la del balanceo de carga (load balancing) o distribución de carga (load distribution) y todas ellas mediante el uso del módulo de apache mod_rewrite.

Para balanceo de carga, necesitamos usar las reglas de tipo RewriteMap (y un script de balanceo) y para distribución de carga con reglas del tipo RewriteRule.

Yo he optado por éste último porque tenía identificado que parte de mi web (no es ésta) generaba mucha carga (imágenes generadas en tiempo real). Por lo tanto, mediante reglas de tipo rewriterule redirecciono todo el tráfico que cumple el patrón (imágenes) y las redirijo al otro servidor (www2.miweb.com). De esta forma, los usuarios sin modificar sus URLs siguen accediendo con total normalidad a toda la web.

En el subdominio www2.miweb.com no es necesario copiar todos los contenidos de www.miweb.com, perfectamente puedes usar enlaces simbólicos a todo o parte de los elementos que se vayan a servir por ese subdominio.

Si no conoces mod_rewrite te recomiendo estos enlaces:

• Apache 1.3 URL Rewriting Guide (en inglés). Una estupenda guía llena de ejemplos prácticos, incluso el de cómo implementar el balanceo de carga con reglas rewritemap.
• Module mod_rewrite URL Rewriting Engine (en inglés). Documentación oficial.
• Mod_rewrite Wizard. Un asistente para generar las reglas de tipo rewriterule. Muy cómodo y recomendable.
• Mod_rewrite cheatsheet. Un “chuletario” de lo más importante del mod_rewrite.

Obviamente, buscando en Google aparecen miles de recursos más y probablemente en castellano, yo no los he buscado, y también es probable que la documentación del Apache2 tenga los mismos manuales actualizados y en español.

Espero que os sirva.

Otro día os comento como evitar al “processwatcher” asesino y conseguir paliar sus “kill -9″ de todos tus procesos

Atención: $1,888 !!!

Creo que estos no se han enterado aun que eso de la burbuja .com estalló hace ya unos cuantos años

El ingenioso método consiste en buscar en Google “producto1 sucks” versus “producto2 sucks” y dependiendo del número de resultados determinas cuan malo o poco “popular” es uno u otro producto o servicio. Este método estadístico-científico es tan versátil y flexible que permite analizar N elementos. Básicamente, es lo que se le puede denominar un suckómetro!

Evidentemente, los resultados no son exactos y tienen todo el rigor que el poder de las masas y de sus quejas lo permitan, pero con cifras de resultados altos, creo que aplica muy bien el dicho de “cuando el río suena, agua lleva”.

Otro valor añadido de Google, quién lo hubiera dicho…

Not only is a 1U x86 server over specified for the average web hosting operation, a Mac Mini is too. An Apple TV is about a third the speed of a Mac Mini, but it costs half as much and draws half the power making it an even more cost effective platform than the Mac Mini. For comparison a Mac Mini is dual 1.66Ghz, 512MB RAM, 60GB disk, versus single 1.0Ghz, 256MB RAM and a 40GB disk in the TV.

Os dejo los enlaces más interesantes que he encontrado:

Hosting:

• AppleTV Dedicated Servers
• MacMini Dedicated Servers

Guías:

• Resources for turning an Intel Mac Mini into a working Linux desktop machine.
• Resources for turning an Apple TV into a working linux desktop machine.