v7 – Rsync + Ec2 + EBS backups en la nube para tus vServers

Después buscar alternativas y posibilidades para la estrategia de backup para la data y maquinas virtuales de vClouden al final encontré una solución simple, financieramente viable y rápida, la cual paso a detallar:

Donde almacenar ?

Aunque como mencione las maquinas EC2 no son precisamente baratas si las comparamos con otros servicios de VPS, lo cierto es que Amazon ofrece uno de las mejores y más económicas soluciones de almacenamiento disponibles (S3 y EBS), la primera para el almacenamiento de objetos y la segunda para el almacenamiento de volumenes para instancias de maquinas EC2, y particularmente importa la segunda por 2 razones:

1) precio:

  • $0.10 por cada GB/mes
  • $0.10 por 1 millón I/O requests

2) redundancia: cada unidad EBS es automáticamente replicada dentro de la zona de disponibilidad en la que se encuentre el datacenter, previniendo perdida de datos por problemas de hardware.

Que mecanismo ?

timemachine

Sigue leyendo

vClouden – Sobre servicios IaaS y arquitectura

Un tiempo ha pasado ya desde la primera implementación de vClouden donde después de mirar y mirar proveedores de servidores me decante por AWS y su conjunto de servicios de almacenamiento y computación; y aunque fue una decisión tomada ello no implica que no siguiera revisando otros proveedores y modelos de virtualización por mero interés, lo que terminó cambiando mi forma de ver los recursos que necesita vClouden para funcionar y escalar.

Cambio de concepción: para vClouden no es necesario un cloud o IaaS complejo

Después de leer, re-leer, hacer pruebas y free trials, la conclusión es muy simple: el vServer es un solo servicio con una sola forma de conexión y por consiguiente no requiere de arquitecturas complejas para sus despliegue (load balancers, private networks, clusters, Queues, AutoScaling, Caching, etc.) así que proveedores como AWS, RackSpace, SendgGrid, Azure, etc. están sobrecalificados si solo vamos a usar sus recursos de computación, en otras palabras: no justifica usar un gran proveedor de IaaS como si fuese un proveedor de VPS, tal como puede verse en sus costos, las maquinas de AWS o RackSpace no son precisamente las más económicas si se les compara con servicios enfocados al vps únicamente como Linode.com (uno de los mas antiguos y respetados) y la razón no son las maquinas en si, es lo que esas maquinas pueden hacer dentro de su ecosistema y la gran cantidad de opciones en arquitectura que nos abren y por su puesto esas posibilidades se reflejan en sus precios, así que si estas usando uno de estos grandes proveedores de infraestructura como un mero VPS tal ves estas pagando demás por una cantidad de posibilidades que no estas usando.

Entonces que tipo de proveedor necesita vClouden ?

Dada su arquitectura vClouden solo requiere de unos puntos estratégicos, básicamente se requiere de un proveedor que:

  1. Tenga un API y pueda generar servers al vuelo.
  2. Que provea un SLA.
  3. Backups automáticos y snapshots de las maquinas creadas.

Se requiere un API dado que vClouden escala horizontalmente, es decir llena un servidor con vServers y automáticamente va añadiendo más para ir creciendo, esto con el fin de que el escalamiento sea automático y predecible, en cuanto al SLA al ofrecer servicios empresariales la estabilidad y disponibilidad es requisito SI o SI y los backups por obvias razones de control de riesgos además que son la base de la estrategia de escalamiento de vClouden.

digitavslinode

Con estos requerimientos y después de revisar varios proveedores quede entre 2 alternativas Linode o DigitalOcean, y despues de jugar con ambos servicios, revisar cuanto post y blog para hacerme una idea de sus reputaciones y problemas, me termine decantando por DigitalOcean dado sus costos, rapidísimo crecimiento en los últimos 2 años, su gran reputación por servicio al cliente y por su puesto su oferta de discos SSD, los cuales el vServer aprovecha en gran medida, simplemente vuelan !!!.

Impensada mejora en la arquitectura:

En ocasiones las mejores soluciones nacen sin pensarlas, como consecuencia de la evaluación de varios proveedores cloud y la definición de la estrategia de backups para la data de los vServers,  vClouden terminó con una arquitectura que es “Cloud  agnostic”, es decir podemos pasar de un cloud a otro sin muchas complicaciones, pues ahora todos los recursos de computo dentro del modelo son “descartables” y dadas las nuevas funcionalidades de LXC la creación de vms toma un par de segundos, por lo que es perfectamente viable pasar un servidor corriendo vClouden con 50 instancias en servidor de DigitalOcean a una maquina de Amazon EC2 en menos de 10 minutos, con lo que de ahora en adelante no estamos atados a ningún proveedor cloud en particular, siempre y cuando un proveedor tenga disponibles las 3 características arriba mencionadas será posible pasar todas las maquinas de vClouden.

Conclusión:

El resultado final de todo este proceso es el traslado a un servicio cloud que se enfoca en lo que vClouden necesita que son servidores puros, permitiendo costos mucho más bajos, discos muuuuuucho más rápidos, preservando las funcionalidades que de por si teníamos con Aws/EC2.

de Cero a mobile con Cirrus.js y Velneo v7

mobile

Parte 1 – Integración de Cirrus.js y vBase:

En este screencast instalaremos Cirrus y vBase desde cero y realizaremos la integración hasta el punto donde el listado de usuarios de vBase es accible via web mediante JSON.

Si deseas ver el video en HD puedes ir a Youtube directamente.

Parte 2 – Aplicación Mobile:

Tomando como base el API del que ahora disponemos vamos a crear una pequeña aplicación mobile usando Trigger.IO desde donde listaremos los usuarios de vBase y generaremos un form para crear nuevos para finalmente correr el app en el Android Simulator.

Si deseas ver el video en HD puedes ir a youtube

La solicitud de inclusión en las OpenApps será enviada la próxima semana pero si no quieres esperar puedes descargar el .vin aqui

Espero la información les sea util y habra nuevos horizontes de desarrollo.

Cirrus.js + Nginx pure Performance

Dado que me han contactado varios miembros de la comunidad de V7 interesados en Cirrus.js me di a la tarea de realizar un load testing usando Blitz.io, digamos que quería saber hasta donde llega Cirrus.js.

Estos son los datos de las prueba:

Maquina: Amazon EC2 m1.medium con 3.7 Ram con una unidad de procesamiento y 2 cores virtuales, para disco use una EBS con IOPS a 400 (Input Output Per Second), corriendo sobre un Ubuntu Server 12.0.4 lts de 64 bits.

Velneo => version v7.7101

Prueba: => Básicamente atacar la ruta “/tareas” que esta definida en la open app de Cirrus.js que toma 10 registros de la tabla tareas y devuelve un JSON.

Resultados:

CONCLUSIÓN.

Como puede observarse básicamente lo que hace el load testing es atacar con usuarios concurrentes el path “/tareas” el objetivo es estresar el servidor para saber con que tanto puede, el resultado: el vServer muere a los 37 segundos mientras soporta 168 concurrentes repondiendoles a un rate de 118 visitas/segundo con lo que se pudieron lograr 3100 visitas en ese lapso de tiempo y pudiendo servir algo asi como 5.6 Millones de requests por día, después de lo cual comienza a dar timeouts y en consecuencia a disminuir el rate y los promedios.

MAS BUENAS NOTICIAS.

La primera:

Este load testing lo realice previo a unas optimizaciones que pienso implementar en el código de Cirrus.js, así que más velocidad esta por venir.

La segunda:

Esta es la mejor, estuve realizando pruebas y al parecer el vServer corre los puertos TCP cada uno en un Thread (hilo) diferente, lo que significa que al levantar sobre diferentes puertos el objeto TCP en el que corre Cirrus.js puedo multiplicar la concurrencia usando Nginx como un load balancer aprovechando todo el performance de su “Non Blocking I/O” y llevar hasta las nubes la capacidad de carga de Cirrus.js sin problemas de enganches.

Un saludo,

pdata: Cirrus.js ya soporta Cookies y sessiones, muy pronto un post documentando la funcionalidad.

Screencast Cirrus.js

En esta presentación veras el funcionamiento y caracteristicas de cirrus.js para darle accesso web a tus apps Velneo v7.

GitHub Repo

Tips:

- Para utilizar los archivos html de ejemplo de esta open App debes de descomprimir el archivo nginx.rar que está dentro del directorio cache de tu vClient.

- Para desarrollo web con v7 te recomiento usar cports para verificar el estado de tus puertos TCP y Fiddler para interceptar y hacer debug de todas las peticiones web-http logrando revisar el request y el response desde diferentes ángulos.

- En la fase de desarrollo es preferible levantar el servidor TCP desde el vClient, por cuanto si lo levantas desde el vServer y haces cambios en tu instancia cuando reinicies instancia el puerto queda abierto pero desligado del vServer y tienes que reiniciar el vserver.

Descarga: Puedes descargar la open app aqui, esta será enviada al catalogo oficial en los próximos días.

Deployment con vClouden

En vClouden las aplicaciones se almacenan como un cabecera que indica los datos básicos de la aplicación (Nombre, logo, cantidad de ram necesario y dependencias) y una serie de versiones que son las que realmente contienen el código fuente de las apps, en cada versión se incluye un archivo tar.gz que contiene la carpeta Velneo (Cajas + Datos server), la indicación de la version de V7 sobre la corre la app y el conscutivo de la versión. Cada versión podrá ser descargada de nuevo, borrada (si no tiene instalaciones asociadas) y por supuesto desplegada en producción.

aquí un video de como trabaja:

Algunas FAQ sobre el almacenamiento y despliegue de soluciones con vClouden:

¿Donde queda almacenado el codigo fuente de mi app ?

El código fuente de tu app queda almacenado dentro el servicio de almacenamiento de Amazon S3 en un repositorio privado el cual se encuentra protegido por todo el sistema de seguridad lógico, físico y de red de Amazon, si quieres hacerte una idea del nivel de seguridad de Amazon AWS esta presentación es mas que completa (http://www.youtube.com/watch?v=hEQIG_6B3VE&feature=plcp).

¿ Que sucede durante un Deployment ?

La secuencia de eventos despúes de que das click en “deploy” es: el servidor revisara todas las instalaciones que tus clientes hayan hecho de tu app y las agrupara por servidor, posteriormente creara una tarea para cada servidor indicandole que instalaciones debe actualizar y a que versión instalar, estas tareas se ejecutaran en 2do plano por un grupo de workers que se encargan de las tareas de despliegue en paralelo.

¿ y si me equivoco en el Deployment ?

Dado que Velneo V7 tiene la característica que al reiniciar instancias reconstruye el área de datos y hace las modificaciones que hayas hecho sobre la estructura de tablas, es posible que te equivoques y que consecuencia de esos cambios de estructura se pierden datos, por ello antes de cada deployment se hace un backup dentro de cada Sandbox (que dura 48 horas) para que puedas realizar un rollback inmediatamente sin perder nada.

¿ Porque debo indicar la cantidad de RAM que consume mi app ?

Porque esa cantidad de RAM será asignada a cada sandbox que correrá tu aplicación, de esta forma se aísla el consumo de memoria para que tu app no afecte el rendimiento de otras instalaciones que corren en el mismo servidor  y viceversa, ademas en función de ese consumo te serán facturadas tus instalaciones una vez establecida la estructura de tarifas de vClouden.

¿ Mi app tiene dependencias de librerías externas, puedo indicarlas ?

Si, aunque de momento se esta probando a nivel de código, vas a poder indicar las librería que necesitas (curl, libxml, Rmagick, etc) y serán instaladas únicamente en cada Sandbox donde se instale tu app.

¿ Que se viene en el tema de deployment ?

- Pues bien, por inquietudes y sugerencias de algunos Velneadores y dado que la arquitectura de vClouden lo permite, en el futuro podrás realizar instalaciones de forma manual desde la interfaz de administración, algo así como un mini sistema de hosting teniendo en tu cuenta un listado de Sandboxs de las que podrás disponer.

- A mediano plazo se esta contemplando el despliegue de deployments basandos en Git, para hacer mas efectivo el control de versiones.

- También se esta probando el poder ver desde el interfaz los logs de tu Velneo vServer y ayudarte así con el debug de posibles problemas que puedas llegar a tener.

bueno esto esto es todo, un saludo.

vServers con alta disponibilidad con Monit

Monit

Monit es una herramienta Linux para monitorizar diferentes componentes de un servidor tales como demonios, archivos, directorios, servicios de red ,etc. pero con una gran diferencia Monit puede tomar acciones por ejemplo cuando el servicio cae y ademas avisarte de lo acontecido, asi que vamos a utilizar esta herramienta para monitorizar un vserver, levantarlo en caso de caida y que nos avise por mail cuando suceda y vamos a hacerlo en un Ubuntu 12.04 LTS.

Primero lo primero installemos Monit:

sudo apt-get install monit

Ahora para monitorizar un proceso Monit necesita que indiquemos un pidfile, pero la instrucciones de arranque de los vServer no tiene la opción “–pidfile”, asi como ejecutamos un Velneo vServer  pudiendo identificar su PID ?, tiempo atras tome unas lineas de codigo de un hilo del foro para crear un script de auto inicio y terminación de un vServer de tal forma que se inicie al igual que los servicios mas comunes para Linux y lo unico que hice fue añadir el codigo para asociarle un pidfile:

#/etc/init.d/vserver_init.sh
#!/bin/bash
 export PIDFILE=/ruta_donde_esta_vserver/vserver.pid
 case "$1" in
 start)
 /ruta_donde_esta_vserver/vServer.sh -s
 ps -e | grep vServer | cut -d" " -f 2 > ${PIDFILE}
 ;;
 stop)
 /ruta_donde_esta_vserver/vServer.sh -t
 rm ${PIDFILE}
 ;;
 restart)
 /ruta_donde_esta_vserver/vServer.sh -t
 rm ${PIDFILE}
 /ruta_donde_esta_vserver/vServer.sh -s
 ps -e | grep vServer | cut -d" " -f 2 > ${PIDFILE}
 ;;
 esac
 exit $?
<strong>

Ok ahora si tenemos un script que podemos usar para iniciar y parar nuestro vServer usando el comando:  “sudo ./vserver_init.sh start”, básicamente lo que este script hace es iniciar el vserver y despues de iniciado lo busca en la lista de procesos activos y guarda su numero de proceso en el archivo .pid especificado en la ruta (PATH), yo personalmente escogí que el pidfile estuviera en la misma carpeta del vserver pero esto es opcional.

Procedamos a configurar Monit, para hacer esto vamos a ir a /etc/monit/monitrc lo abrimos con un editor (vim por ejemplo) y buscamos la siguientes lineas y las editamos:

set daemon 30 #revisa los servicios en intervalos de 30 segundos

#asignemos un servidor de mail via SMTP, intentalo con tu cuenta de Gmail

set mailserver smtp.gmail.com port 587

username “MYUSER” password “MYPASSWORD”

using tlsv1

set alert pedro_perez@mail.com #asignemos a quien enviar los correos

#Monitorizar tu vserver

check process vServer with pidfile /ruta_donde_esta_vserver/vserver.pid

start program = “/etc/init.d/vserver_init.sh start”

stop program = “/etc/init.d/vserver_init.sh stop”

if failed host 127.0.0.1 port 690 type tcp then alert

if 5 restarts within 5 cycles then timeout

Basicamente lo que hicimos fue decirle a monit: revisa mi vserver cada 30 segundos, estos son los comandos para inciarlo y detenerlo, en caso de caida levántalo y  notifícame a mi correo usando el servidor de correo de Gmail, si se cae mas 5 veces durante 2 minutos y medio terminalo.

no es Genial …

por supuesto Monit tiene mas para dar: un servidor web embebido para que puedas acceder via http y revisar el estado de los servicios, monitorizar carpetas (muy util para los vServers Express así obtendríamos notificaciones cuando se este acabando el espacio en disco), monitorizar archivos, comunicaciones TCP, etc.

pdta: en vClouden cada Sandbox tiene su propio Monit para cuidar el server.