CloudAdmins.org

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

Por eso, hemos creado un listado con sus posibles alternativas. A ver que os parece y si conocéis algunas más, no dudéis en postearlo en el Grupo de LinkedIn de Cloudadmins, bienvenido será. Saludos. http://www.linkedin.com/groups/Alternativas-productos-Amazon-Web-Services-4443594.S.240657461

• Route53 -> CloudFlare
• SES -> sendgrid
• SNS-> mailchimp
• alternativa a EC2-> Rackspace, Google Compute Engine, GoGrid
• EC2 interface com-> OCCI
• EC2 software -> OpenStack and OpenNebula, Eucalhyptus
• RDS-> http://www.cloudadmins.org/2012/11/rds-no-es-la-unica-solucion-dbaas/
• Dynamo DB -> Cassandra, Cloudant Data Layer (CouchDB), Datastore on Google Appengine, OpenLink Virtuoso, HannaDB, Freebase
• Cloudfront -> Akamai
• ElasticCache -> Apache Solr o Lucene
• OpsWorks -> Chef, Puppet
• Aws S3 -> – dropbox, skydrive, livedrive, box, google, mozy, opendrive
• ELB -> ¿corosync, pacemaker, heartbeat, haproxy?

Como dice el título, ¿delegar la seguridad del departamento TI puede incrementar los beneficios de una empresa? De ello nos intentaron convencer en el evento Cloud Security 2013 que se llevo acabo a principios de Febrero gracias SVT CloudServices. En él Josep Bardallo, CEO de SVT, nos presento la compañía y nos mostró el punto de vista de SVT sobre el estado actual de la seguridad en la nube, también conocido como SECaaS. Un interesante análisis de aproximadamente 10 minutos que podéis ver a partir del minuto 20 en el siguiente vídeo.

Además contó con la participación de varias empresas que dieron a conocer casos de éxito al utilizar productos Cloud de SVT. En todos ellos se enfatizaba el hecho de que confiar en las soluciones de SEECaaS les había permitido dedicar todos sus esfuerzos a lo que realmente sabían hacer. Interesante el caso de Roberto Lorente, responsable de sistemas de unos laboratorios farmacéuticos, en el que narra los conflictos que le había generado la LOPD, entre otros, para adquirir este tipo de servicios en su aparición. También pudimos conocer de primera mano, por parte de Pau García Milà, del próximo lanzamiento de eyeOS. 

En este evento de SVT, como proveedor de servicios SEECaaS, se destaco el hecho pago por uso como ventaja frente al pago de licencias por usuario o equipo, como una de las principales ventajas frente a otros proveedores de servicio. Sin dejar a un lado los otros beneficios de flexibilidad, agilidad y escalabilidad que se derivan de utilizar este tipo productos.

Finalmente presenciamos una demostración hacker en directo bastante decepcionante. Nos mostraron como con técnicas muy sencillas (google hacking, sql injection básico,  traceroute…) se puede llegar a obtener información critica además de algunas de los productos que ofrece, Cloudjacket.  También echamos de menos un turno preguntas, sobre todo en esta última parte.

Después de varias pruebas con Puppet, ir a la Puppet Camp, reuniones de la puppet-users-barcelona y la ayuda de la fabulosa gente del puppet-users-barcelona (https://groups.google.com/forum/?hl=en&fromgroups=#!forum/puppet-users-barcelona). Hemos creado esta pequeña introducción de una de las posibilidades de utilizar Puppet en Amazon EC2. Aunque Amazon hace poco lanzó el producto OpsWorks (https://aws.amazon.com/opsworks/) basado en Chef (http://finance.yahoo.com/news/amazon-services-chooses-opscode-chef-181000793.html). Por ahora, nosotros preferimos utilizar Puppet antes que Chef, porqué hay mucha documentación, mucha más comunidad y nos gusta más. Y por el momento vemos muchos más casos de éxitos de empresas importantes con Puppet que con Chef.  Ejemplo de Pinterest, Wuaki.tv, Zynga, etc.

Recomendamos leer alguna Introducción de como funciona Puppet antes de leer este POST. En Google se pueden encontrar muchos (http://www.ant30.es/2011/11/puppet-gestion-de-configuracion-centralizada/)

Escenario 1: Puppet Master como nodo central.

Recordad que Puppet se presenta en dos partes: un servidor (el Puppetmaster), que recibe las conexiones de los clientes y contiene los manifests, módulos, plantillas, archivos, etc. Y luego un programa cliente que se ejecuta en cada máquina bajo control de Puppet y que se conecta mediante intercambio de certificados al PuppetMaster para conseguir su manifests.

Paquetes a instalar:

Si queremos trabajar con un PuppetMaster y nodos de puppet conectándose al Puppet Master. Primero debemos instalar mediante nuestro sistema de paquetería de nuestro Sistema Operativo los paquetes “puppet” y “puppet-master” en la máquina elegida como servidor. Luego instalamos en cada nodo cliente el paquete “puppet”.

En el servidor:

En el cliente:

Resolución de nombres:

Una vez instalados los paquetes, tendremos que hacer una sencilla configuración de Puppet. Aunque antes tendremos que forzar a todas las máquinas que el nodo llamado “puppet” apunte a la IP del puppetmaster. Por eso lo podemos hacer mediante DNS y sinó podemos porqué nosotros no controlamos el DNS, lo podemos hacer modificando el fichero “/etc/hosts” de cada máquina que contenga Puppet.

Para eso editamos el “/etc/hosts” de todas nuestras máquinas. Si por ejemplo el puppet master tiene la IP 192.168.1.20 la cosa quedaría de la siguiente forma:

Si estuviésemos dentro del Puppetmaster lanzado el siguiente comando ya bastaría:

Configuración:

Luego necesitamos editar 2 ficheros.

/etc/puppet/puppet.conf (en teoría ya viene por defecto configurado correctamente)

Miramos si existe el fichero /etc/puppet/autosign.conf, si no existe lo creamos.

Dentro del fichero /etc/puppet/autosign.conf solo hace falta que contenga una “*” que significa que toda petición de un nodo cliente que se conecte se autofirme para ahorrarnos hacerlo manualmente. Esto tiene inconvenientes de seguridad porqué todo nodo con visibilidad al PuppetMaster se podria connectar al él. Por lo tanto tendríamos que proteger la red de nodos no deseados (cerrando los puertos de Puppet). Con Security Groups de Amazon se puede solucionar o con un IP tables o con otros métodos. También podriamos configurar el PuppetMaster para firmar solo un cierto rango de IPs o ciertas máquinas que contengan estén en un subdominio de DNS. Aquí os recomendamos que busquéis en la documentación oficial de Puppet.

En este caso, el autosign.conf queda así:

Si acabamos de preparar el servidor Puppetmaster y queremos conectar un nodo cliente de puppet. Antes se tiene que pasar los certificados con el comando y con el mismo comando se lanza también el Puppet.

 Si solo quisiesemos lanzar el nodo las veces que nosotros quisiesemos, por ejemplo al arrancar la máquina, y no mediante el demonio de Puppet. Tendríamos que apagar el demonio de Puppet y lanzar el siguiente comando:

También tenemos la forma de probar nuevas modificaciones de Puppet sin aplicar cambios mediante el siguiente comando. Es decir para poder debugar antes.

# puppet cert –list –all

En el caso que no tuviesemos puesto el método comentado anteriormente para firmar automáticamente, podemos firmar manualmente los nuevos nodos de puppet a conectarse al Puppetmaster, mediante el siguiente comando:

En el Pupetmaster podemos revocar el certificado del nodo:

Para limpiar el nodo.

O para limpiar todos los nodos.

Varias cosas a tener en cuenta.

- Este es un ejemplo de muchas posibles. Hay otras opciones de autoregistrar las máquinas en un DNS como el AWS Route 53.

- Si encontráis algún error o que falta algo o que nos hayamos dejado algo. O conoceis otras formas de trabajar con EC2, no dudéis en comentarlo en el grupo de CloudAdmins de LinkedIn.

- Cuando reiniciamos las máquinas virtuales de Amazon, o creamos una AMI, podemos perder el hostname correcto de la máquina. Por lo tanto, nosotros solemos poner en el rc.local , lo siguiente para que la máquina se encienda con el hostname adecuado.

Escenario 2 : Sin nodo central Puppet Master. Todo en una sola máquina.

Mirar que fácil y que sencillo es con este método que utilizábamos en nuestros primeros tests.

Primero mediante “apt-get”, yum o equivalente instalamos el: git y puppetmaster.

# apt-get install puppetmaster git

Nos bajamos el código con nuestros manifests de Puppet. Por ejemplo con Git (también podriamos utilizar SVN, wget o lo que nos gusté más). En nuestro ejemplo:

Y luego lanzamos el puppet mediante:

De esta forma la máquina hace de Puppetmaster y a la vez de cliente Puppet. Sin falta de firmar certificados y configuraciones complicadas. Lástima que aquí perdemos potencialidad de la que nos ofrece Puppet (guardar storeconfigs, los facters, etc.)

Estas 2 líneas las podríamos poner en nuestro “rc.local” del sistema operativo para que cada vez que arranque la máquina de Amazon EC2 se puppetize el entorno.

En este artículo queríamos dar las gracias a la gente de puppet-users-barcelona ( https://groups.google.com/forum/?hl=en&fromgroups=#!forum/puppet-users-barcelona ) por su ayuda, por la fabulosa PuppetCamp que organizaron y por las reuniones mensuales que hacen. Desde aquí os comentamos que es muy recomendado ir .

Referencias interesantes:

http://www.slideshare.net/roml/puppetcamp-15934250
http://kentbye.com/post/32415279029/how-pinterest-uses-amazon-ec2s-auto-scaling-features
http://www.slideshare.net/markstanislav/being-a-puppet-master-automating-amazon-ec2-with-puppet-friends

Sam Silverberg, desarrollador con una dilatada experiencia está al frente del proyecto Opendedup. Opendedup se centra en el desarrollo de nuevos sistemas de ficheros con el objetivo de dar solución e ir más allá en el terreno de la deduplicación en línea. Si analizamos su “core” Opendedup ha desarrollado y apuesta por SDFS, un sistema de ficheros multiplataforma con deduplicación en línea que permite reducir en más del 90% el espacio utilizado, permite deduplicar más de un Petabyte de datos, ofrece rendimientos superiores a 1Gbps, se integra con entornos de virtualización de VMWare como repositorio de máquinas virtuales, soporta “snapshots” a nivel de ficheros o directorios, etc…

http://opendedup.org/whatisdedup

Siendo fiel al título de este POST, veremos como SDFS nos puede ayudar en la optimización del uso de recursos en proveedores Cloud para fines como por ejemplo de archivado, dónde este permite almacenar “bloques” deduplicados sobre servicios de almacenamiento en la nube como son Amazon S3 o Azure. Cosa que facilita almacenar una cantidad ilimitada de datos sin la necesidad de almacenamiento local con capacidades de cifrado (AES 256 bit) y compresión (obvia y por defecto).

Si lo analizamos más en detalles, los beneficios están bastante claros ya que reducimos al mínimo el almacenamiento externo, uso de ancho de banda y maximizamos aspectos como el rendimiento de escritura.

Como detalle adicional es importante tener en cuenta que el enfoque de almacenamiento externo mediante bloques requiere que el espacio de nombres y los metadatos de archivos se almacenen localmente en el sistema en el que se monta el volumen SDFS, esto asegura por un lado el máximo rendimiento al permitir que todas las funciones del sistema de archivos se realizan a nivel local a excepción de los datos de lecturas y escrituras pero por otro nos limita a utilizar la misma máquina para acceder a los datos.

En base a su tutorial de uso y si entramos en el caso específico de volúmenes deduplicados sobre AWS S3:

1) Realizaremos la instalación de opendedup – http://opendedup.org/download

2) Utilizando las credenciales que nos proporciona Amazon AWS para su servicio S3 y con un ‘bucket’ ya disponible crearemos un volumen SDFS :

./mkfs.sdfs  –volume-name=<volume name> –volume-capacity=<volume capacity> –aws-enabled=true –cloud-access-key=<the aws assigned access key> –cloud-bucket-name=<a universally unique bucket name such as the aws-access-key> –cloud-secret-key=<assigned aws secret key> –chunk-store-encrypt=true

3) Montaremos el volumen y a jugar…

./mount.sdfs <volume name> <mount point>

Salud!

Cloudadmins.org

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

 
global_defs {
    notification_email {
        alerts@cloudadmins.org<script type="text/javascript">
/* <![CDATA[ */
(function(){try{var s,a,i,j,r,c,l,b=document.getElementsByTagName("script");l=b[b.length-1].previousSibling;a=l.getAttribute('data-cfemail');if(a){s='';r=parseInt(a.substr(0,2),16);for(j=2;a.length-j;j+=2){c=parseInt(a.substr(j,2),16)^r;s+=String.fromCharCode(c);}s=document.createTextNode(s);l.parentNode.replaceChild(s,l);}}catch(e){}})();
/* ]]> */
</script>
    }
    notification_email_from keepalived@haproxy01.cloudadmins.org<script type="text/javascript">
/* <![CDATA[ */
(function(){try{var s,a,i,j,r,c,l,b=document.getElementsByTagName("script");l=b[b.length-1].previousSibling;a=l.getAttribute('data-cfemail');if(a){s='';r=parseInt(a.substr(0,2),16);for(j=2;a.length-j;j+=2){c=parseInt(a.substr(j,2),16)^r;s+=String.fromCharCode(c);}s=document.createTextNode(s);l.parentNode.replaceChild(s,l);}}catch(e){}})();
/* ]]> */
</script>
    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

Hola a todos,

Seguramente viendo el título de este POST y de un primer vistazo te preguntarás que tiene que ver  las vacunas con la disponibilidad de los servicios, yo también me hice esa pregunta….

A día de hoy la información es uno de los activos más importantes de cualquier organización. Mantener la confidencialidad, la disponibilidad y la integridad puede llegar a ser una tarea esencial para mantener los niveles de competitividad y rendimiento de cualquier empresa con el objetivo de conseguir beneficios. Actualmente podemos ver como emergen proveedores de soluciones SECaaS (Security as a Service) como Novell, McAfee, Symantec, etc.

Es “archiconocido” que todos los sistemas de la información, plataformas TI, están expuestas a un número ingente de amenazas. Aprovechando cualquiera de las vulnerabilidades conocidas o por conocer (0-day) pueden someter cualquier activo crítico de información a espionaje, sabotaje, fraude, etc.

En esta línea y con el objetivo de reducir los llamados “cyberriesgos” tuve la oportunidad de asistir a principios del 2012 al Fourth Workshop on Cyber Security and Global Affairs and Global Security. En él Arun K. Sood mostró en su presentación unos datos que me impactaron:

En la figura podemos observar que la brecha de  tiempo entre la intrusión y la respuesta ante el ataques es muy alto. En este intervalo de tiempo un atacante ha podido comprometer información crítica de nuestra organización si no disponemos de las herramientas adecuadas que nos ayuden a disminuirlo. En el siguiente documento podréis obtener información detallada y muy extensa sobre este tema: INFORME SOBRE INVESTIGACIONES DE BRECHAS EN LOS DATOS DE 2012.

Arun K. Sook es el fundador de SCIT Labs, spin off de la universidad George Mason, tiene como objetivo crear un framework de clusters de servidores securizados.  Este producto, con el objetivo de acercarse al paradigma de 100% de uptime en todos los sentidos, incluye la mitigación del posible compromiso del propio contenido o información. Este proyecto ha sido bautizado con el nombre “the digital vaccine” y tiene como objetivos principales:

• Asegurar la disponibilidad de los servicios en infraestructuras críticas.
• Tolerancia cero a cualquier tipo de  intento de intrusión.
• Conseguir un nivel redundancia o backup óptimo.

La técnica: La “vacuna” utiliza máquinas virtuales que van rotando cada 60 segundos o menos.  Cada intervalo de rotación se proporciona nuevos servidores que han estado “limpiados” y/o restaurados, este proceso se va repitiendo sucesivamente.

Pese a la ambición de este proyecto no se han visto avances significativos o detalles técnicos en artículos sobre su funcionamiento. Aún así estaremos atentos a lo que va dar de si este workshop en la edición de 2013 (Cyber Resilience Workshop Series) que se llevará a cabo a final de mes y que seguiremos desde cloudadmins.org.

Hasta el próximo POST.  Nos vemos,

Iván Farré – Cloudadmins.org

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

·

Hoy se ha celebrado la PuppetCamp en Barcelona y ha sido un gran éxito. http://puppetcampbarcelona2013.eventbrite.com/ Con unos ponentes muy buenos y con grandes conocimimentos sobre Puppet. Se han tocado temáticas de todos los niveles:

• State of Puppet: Chris Spence
• Test driven Infrastructure development: Tomas Doran http://t.co/w5iELzzziV
• Very Good Things To Know About Puppet In 20 minutes – Gary Wilson
• Puppet and Telefonica R&D – Xavi Carrillo
• Mimicking your Java EE production environment for testing and beyond – Alex Soto
• Hiera 101 – Francisco Martínez
• zpf – the elusive zero point of failure – Gary Wilson https://github.com/earthgecko/zpf
• Puppet Demo: Chris Spence

Agradecer a la gente de TID (Telefónica I+D), a la gente de Puppet Users Barcelona (https://groups.google.com/forum/#!forum/puppet-users-barcelona) y a la misma gente de Puppet Labs por tan buena organización.

Aprovechamos este POST para presentar el vídeo del seminario de la Webinar de “Automatizando entornos de TI con Puppet” dictado por Edrans y Puppet Labs. Si no pudo participar en su momento, ahora puede repasar el mismo en su versión grabada, y realizar sus preguntas en el grupo de Puppet para el habla hispana (Grupo de Puppet para habla hispana: http://bit.ly/15GQqoC )

Un CloudAdmin

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.