Categories
General

Cloudenlaces – Diciembre 2013

Recuperamos los enlaces más interesantes del mes de diciembre:
– Testeando el balanceador con Honeypot Daemon
– Como simplifican los aprovisonamientos en Yammer con Deploymacy
– Una presentación muy interesante sobre la adopción del modelo de entrega contínua en la empresa
– Testeando CLI con RSpec y Cucumber-less Aruba
– Por último os acompañamos a que rellenéis una pequeña encuesta sobre un tema que en algunas ocasiones chispea… por no decir chisporrotea.
¿Quién es el responsable de la seguridad de una aplicación?

Categories
Bigdata General Hybrid Clouds In detail OpenSource

Cassandra, analizado en la última edición de Sudoers

Hemos tenido el placer de asistir a la reunión de Mayo de Sudoers donde Roger Torrentsgenerós expuso Keepalived y Tomàs Núñez explicó Cassandra para sysadmins.

Ya hablamos de Keepalived. Y Cassandra se nombró muy brevemente aquí, pero sin entrar en muchos detalles. Así que vamos a aprovechar para hacer un resumen de la presentación sobre Cassandra.

Como ya sabéis Cassandra es una base de datos NoSQL descentralizada. Está diseñada para trabajar con grandes volumenes de datos y permite escalar horizontalmente de una manera muy fácil.

Está basada en Google Bigtable y Amazon Dynamo, fue desarrollada inicialmente por Facebook. Des de febrero de 2010 es un Top Level Project de Apache y la última versión es la 1.2.5.

Actualmente es un projecto con una comunidad muy activa y existen diversas compañías que se dedican a dar soporte, como por ejemplo Datastax. Grandes compañías tienen Cassandra en sus entornos de producción: Facebook, Twitter, Netflix, Digg, Groupalia, etc.

Los puntos fuertes de Cassandra son:

  • Las escrituras son realmente rápidas (3000x respecto a MySQL).
  • Al ser descentralizada no tiene un Single Point of Failure.
  • Alta disponibilidad viene de serie.
  • Escala horizontalmente.
  • Requiere de muy poca administración.
  • Está pensada para correr sobre hardware barato.

Respecto al modelo de datos destacar que cada objeto tiene un ID y una serie key-value-timestamp. Al ser un modelo ‘sparse’ esto le da gran flexibilidad ya que no todos los elementos de una tabla deben tenen los mismos atributos e incluso se puede alterar el número de atributos sin bloquear la tabla o tener que parar el servicio.

Respecto a la arquitectura decir que se basa en un modelo DHT (Distributed Hash Table) donde los nodos se distribuyen en forma de anillo y cada nodo es el reponsable principal para una partición y el responsable secundario para una o más particiones (dependiendo del factor de replicación que es configurable). También es posible configurar la arquitectura de manera que sea multirack o multidatacenter.

Gracias al proceso de Gossip, todos los nodos saben en todo momento los nodos disponibles, su carga y si están bajo mantenimiento o la versión de Cassandra que están corriendo.

Como ya hemos comentado las escrituras en Cassandra son muy rápidas, ya que no se preocupa de recuperar el valor (si existe) para actualizarlo, sino que escribe directamente como si el valor fuese nuevo. Esto hace que en el momento de la lectura, se tengan que recoger los valores y ver cual es el más reciente.

Como curiosidad decir que se puede definir índice secundarios y des de la versión 0.8 hay soporte para contadores.

Existe una herramienta para el mantenimiendo y admininistración de los nodos llamada nodetool, recomiendo echar un vistazo a la wiki de Apache para ver los detalles de esta versátil herramienta.

Una manera muy sencilla de hacer una copia de seguridad es definir un cluster de backup con un nodo donde se almacenaránn todos los datos, y hacer la copia de este nodo.

La parte más interesante de la presentación fue cuando el ponente hizo gala de su dilatada experiencia con Apache Cassandra y nos explicó una serie de errores frecuentes y algunas optimizaciones. Recomiendo encarecidamente su lectura http://www.tomas.cat/blog/en/cassandra-frequent-mistakes.

Tan solo felicitar a Tomas por su excelente presentación.

Por último podéis encontrar la presentación original aquí.

Espero que lo disfrutéis 😉

Lorenzo  Cubero – CloudAdmin

Categories
Guide In detail OpenSource

Alta disponibilidad en la capa de balanceo con HAProxy y Keepalived




Prácticamente ya no cabe pensar en servicios en la nube sin suponerles alta disponibilidad (HA). Como usuarios estamos mal acostumbrados,  ¿por qué quien sigue utilizando un servicio que no se encuentre disponible, aunque sea de manera casual?
La alta disponibilidad ha pasado a ser una commodity. Y ya no hay empresa, con un modelo de negocio capaz de soportar periodos regulares de no disponibilidad de su servicio, ya que eso implica grandes pérdidas económicas. ¡Más que nunca el tiempo es oro!
Existen diferentes herramientas o servicios que nos facilitaran el despliegue de nuestras aplicaciones con garantías HA, como: Keepalived, Pacemaker, Heartbeat, HAProxy, etc. Siendo éstas de diferente naturaleza (unas funcionan a nivel de aplicación, otras a nivel de HTTP/TCP…) y pudiendo ser combinadas según nuestras necesidades. Por ejemplo, una combinación muy común es Heartbeat y Pacemaker.

Quisiera hacer especial mención a HAProxy un projecto matenido por Willy Tarreau. Es un proyecto ya consolidado, la primera versión es del 2001 y empezó siendo proxy con balanceador de carga muy sencillo. Ha ido evolucionando y a día de hoy se haya convertido una herramienta muy interesante. El projecto se mantiene activo y van saliendo nuevas versiones que van incorporando nuevas funcionalidades como servir de terminación de SSL, analizador de logs, protocolo RDP, soporte para autenticación HTTP, estadísticas y monitorización… incluso incluye una interfaz web donde consultar el estado actual del proxy.

Si el servicio de balanceo de tu proveedor de cloud no te convence, ya que quieres llegar más allá y como el objetivo es no introducir un nuevo punto único de fallo en nuestras aplicaciones, vamos a ver un ejemplo práctico de como configurar un par de instancias HAProxy en modo activo-pasivo mediante Keepalived. Básicamente lo que haremos será mover dirección IP del servidor activo al pasivo cuando el primero deje de estar disponible.
Direcciones IP utilizadas

  • 10.1.1.10 Servidor Syslog
  • 10.1.1.30 Backend Web #1
  • 10.1.1.31 Backend Web #2
  • 10.1.1.20 Servidor HAProxy #1 dirección de gestión
  • 10.1.1.21 Servidor HAProxy #2 dirección de gestión
  • 10.1.1.80 Esta es la dirección del proxy que los usuarios conocen, Keepalived hará que apunte a un servidor disponible.
  • 10.1.1.25 Servidor SMTP

Instalación y configuración de HAProxy

En Ubuntu basta con hacer sudo apt-get install haproxy, poner ENABLED=1 en el fichero /etc/default/haproxy para habilitar el script de inicio y aplicar la siguiente configuración en /etc/haproxy/haproxy.cfg:

global
     log 10.1.1.10 local0
     user haproxy
     group haproxy
     daemon
     maxconn 20000
     defaults
     log global
     option dontlognull
     balance leastconn
     clitimeout 60000
     srvtimeout 60000
     contimeout 5000
     retries 3
     option redispatch
listen stats 10.1.1.20:80 # se podría poner 10.1.1.21:80
     mode http
     stats enable
     stats uri /stats
     stats realm HAProxy\ Statistics
     stats auth admin:PASSWORD
listen http 10.1.1.80:80
     mode tcp
     option tcplog
     balance source
     maxconn 10000
     server web01 10.1.1.30:80 maxconn 6000
     server web02 10.1.1.31:80 maxconn 6000
listen https 10.1.1.80:443
     mode tcp
     option tcplog
     balance roundrobin
     maxconn 10000
     server web01 10.1.1.30:443 maxconn 6000
     server web02 10.1.1.31:443 maxconn 6000

Finalmente iniciamos el servicio service haproxy start.
Instalación y configuración de Keepalived
En Ubuntu basta con hacer sudo apt-get install keepalived, y aplicar la siguiente configuración en /etc/keepalived/keepalived.conf:

global_defs {
    notification_email {
        alerts@cloudadmins.org
    }
    notification_email_from keepalived@haproxy01.cloudadmins.org
    smtp_server 10.1.1.25
    smtp_connect_timeout 30
}
vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 2 # check cada 2 segundos
    weight 2 # añade 2 puntos de prioridad si OK
}
vrrp_instance VI_1 {
    interface eth0
    state MASTER # "BACKUP" en el servidor de respaldo
    priority 101 # 101 en el master, 100 en el respaldo
    virtual_router_id 51
    smtp_alert # Activar notificaciones SMTP
    authentication {
        auth_type AH
        auth_pass PASSWORD
    }
    virtual_ipaddress {
        10.1.1.80
    }
    track_script {
        chk_haproxy
    }
}

Finalmente iniciamos el servicio service keepalived start.
Y con estos sencillos pasos ya tenemos nuestro frontend web balanceado en alta disponibilidad.
Espero que los disfrutéis 😉
Referencia usada http://haproxy.1wt.eu/download/1.3/doc/architecture.txt

Categories
General Monitoring OpenSource

Monitorizando ejecuciones en Puppet

Hace unos días encontré este interesante artículo sobre monitorización de acciones en herramientas de gestión de configuraciones.
http://highscalability.com/blog/2013/2/19/puppet-monitoring-how-to-monitor-the-success-or-failure-of-p.html
El artículo explica que más allá de las bondades de este tipo de utilidades, el funcionamiento de éstas también debe ser monitorizado.
También entra en detalle de como atacar este problema en sistemas basados en Puppet mediante el uso de MCollective.
Espero que los disfrutéis 😉

Categories
Bigdata General Hybrid Clouds

Ofreciendo Simple Storage Service

Hace algún tiempo, nos vimos en la tesitura de ofrecer servicios de Cloud Storage compatibles con S3. Estuvimos estudiando el mercado, y nos encontramos con Cloudian Multi-tenant S3 Cloud Storage. Básicamente se trata de una plataforma para ofrecer servicios de Cloud Storage mediante una API compatible con S3.

http://www.cloudian.com/overview.html
La idea es bastante interesante. A un cliente que ya se encuentre trabajando con los servicios de Amazon, le resultaría casi trivial cambiar de proveedor de almacenaje en la nube.
La plataforma está muy bien pensada: el contenedor final de los datos está basado en una base de datos noSQL , Apache Cassandra. Dispone de una  Consola de Administración web, que incluso genera informes contables. E incluso viene con un agente de Zabbix para la monitorización del servicio.
En cuanto al modelo de negocio de Cloudian Inc., se puede usar la plataforma de forma totalmente gratuita hasta 100TB de almacenamiento. Empezando a partir de ahí los planes de pago.
Como véis Cloudian está pensado para organizaciones que quieran ofrecer servicios de Cloud Storage a sus clientes.Aunque se trata de una solución muy joven, hay que decir que la versión 2.3 es muy estable y el soporte es muy competente. Por último comentar que Cloudian es capaz de utilizar los servicios S3 de Amazon en caso de que la demanda de almacenaje lo requiera.