Categories
Bigdata General NoSQL OpenSource Social

Datos en formato Grafo (NoSQL) – 1a Entrega

Actualmente las base de datos NoSQL están en auge (http://nosql-database.org). Podemos encontrar una gran diversidad según su arquitectura; las más utilizadas son del tipo Key-Value (como Cassandra o Voldemort) 
o las documentales (por ejemplo MongoDB y CouchDB). Aunque existen otras no tan conocidas como las que os queremos presentar; BBDD NoSQL basadas en grafos o tripletas como DEX y Neo4j. (http://stackoverflow.com/questions/5689091/how-to-choose-which-type-of-nosql-to-use). A parte luego ya hay base de datos NoSQL que ya son casos híbridos que es el caso de OrientDB (http://www.orientechnologies.com/orientdb) que es un híbrido orientado entre base de datos en formato grafo y documentales.
dex
Dex introducción
Os queríamos introducir DEX una base de datos NoSQL de grafos con muchos casos de éxitos. DEX (http://www.sparsity-technologies.com/dex) está escrita en C++ aunque se puede utilizar con muchos otros lenguajes de programación y una de sus características principales es que permite analizar grandes volúmenes de datos.
DEX está basado en el modelo2 de base de datos en grafo, que está caracterizado por cumplir 3 propiedades: las estructuras de los datos son grafos o estructuras similares a un grafo o tripleta, la manipulación de los datos y las consultas se realizan con operaciones orientadas a grafo y existen restricciones para garantizar la integridad de los datos y de sus relaciones.
Un grafo de DEX es un multigrafo dirigido etiquetado y con atributos. Está etiquetado porque tanto nodos como aristas pertenecen a tipos. El grafo es dirigido porque permite que existan tanto aristas dirigidas como no dirigidas. Nodos y aristas pueden tener tantos atributos como se desee. Finalmente también decimos que es un multigrafo porque permite que existan múltiples aristas entre dos nodos aunque éstas sean del mismo tipo.
La principal característica de DEX es su capacidad de almacenamiento de datos y rendimiento, con órdenes de magnitud de miles de millones de nodos, aristas y atributos, gracias a una implementación con estructuras ligeras especializadas. (Wikipedia)

Ref: http://www.cbsolution.net/techniques/ontarget/databases_relational_vs_object_vs

Dex comparación con mysql

Depende mucho de cada caso de uso para saber cuando es más recomendado usar DEX u otro tipo de base de datos. Hemos querido hacer una típica comparación comparando DEX con MySQL. Elegimos MySQL ya que es una de las base de datos más usadas actualmente. Podemos ver en el siguiente listado que ventajas y desventajas nos aportan una base de datos relacional como el MySQL en comparación con una de grafos como DEX.

Ventajas del Mysql:
  • Mejor medición del performance (DEX tiene herramientas pero no suelen ser en tiempo real como pueden ser en MySQL)
  • Madurez. Está claro que las RDB como el MySQL son más maduras que DEX. Este hecho aporta que a nivel seguridad el MySQL es también más maduro y su interfície de gestión es más avanzada.
  • Claramente hay muchos más casos de éxito del MySQL
  • La implementación de MySQL es sencilla y además la mayoría de gente tiene más experiencia en este ámbito de las RDB. Siguiendo a nivel coste, DEX vuelca todos sus datos en RAM por lo cual es más costoso a nivel Hardware que las RDBs. Aunque actualmente el precio de la RAM se está reduciendo cada vez más.
  • Escalabilidad. Curioso caso, el NoSQL suele ser muy utilizado por las carencias de MySQL a nivel escalabilidad. El DEX en sus primeras versiones cojeaba un poco a nivel escalabilidad. Aunque tenemos que estar atentos porque las últimas versiones de DEX mejoran mucho esta característica y quizás este punto ahora sea más favorable para DEX.
Ventajas DEX sobre Mysql:

Ahora viene la parte interesante:

  • Aparentemente MySQL es más ineficiente para modelos de datos complejos o datos flexibles.
  • Es ineficiente para consultas estructurales. O para uso intenso de JOINS.
  • El DEX permite gran capacidad de tratamiento de grandes volumes con un alto rendimiento
  • Los Grafos suelen ser muy utilizado en redes sociales y en el mundo del Big Data.
  • El DEX se puede integrar con dos base de datos públicas.
  • WordNet: definiciones y diccionarios.
  • ConceptNet: relaciones entre conceptos.
  • Muy flexible para manejar Schemas desconocidos o dinámicos
  • El DEX tiene unas consultas estructurales y permite la navegación entre consultas.
  • Fácil mapeo entre ficheros CSV a DEX.
  • Tal como hemos comentado la escalabilidad a mejorado mucho en las últimas versiones. Cosa que seguramente ahora será mejor que el MySQL en este ámbito. Está aun por probar por parte nuestra.

Algunos casos para usarse de forma mucho mejor que MySQL u otras base de datos RDB y NoSQL:
– Encontrar todos los caminos entre 2 saltos de distancia (http://docs.neo4j.org/chunked/stable/cypher-query-lang.html)
– Encontrar amigo con el que tienes más amigos en común. Como también dar recomendaciones de grupos o música.
– Encontrar el camino más cortos entre dos elementos.
– Dijkstraa con DEX: http://architects.dzone.com/articles/graph-databases-features-graph
– Poner pesos entre diversos nodos con un coste. De esta forma podemos buscar el coste más pequeño entre nodos de distintos intereses entre todos . http://docs.neo4j.org/chunked/stable/tutorials-java-embedded-graph-algo.html
Ejemplo simple de un HelloWorld con DEX

public class HelloWorld {
DEX dex = new DEX();
GraphPool gpool = dex.create("/tmp/image.dex");
gpool.close();
dex.close;
System.out.println("Hello, World");
}

En la web de DEX podeis encontrar muchos más ejemplos. (http://www.sparsity-technologies.com/dex)

Las alternativa a DEX

La más conocida y más utilizada a parte de DEX es Neo4j. http://en.wikipedia.org/wiki/Neo4j . También tiene varias versiones como DEX. En el caso del Neo4j, tiene 3 versiones:

  • Comunidad está licenciado bajo GPL, y contiene toda la graphiness impresionante que deseas
  • Advanced es AGPL licencia, y agrega capacidades de seguimiento para su base de datos
  • Enterprise es también AGPL licencia, y agrega el monitoreo, las copias de seguridad en vivo y alta disponibilidad.

A parte de DEX y Neo4j que son las más utilizadas también hay muchas otras más, os recomendamos la siguiente lectura: http://jasperpeilee.wordpress.com/2011/11/25/a-survey-on-graph-databases/
Y por cierto, esta imagen hace un muy buen resumen y clasificación del estado del arte de como esta actualmente el mundo del SQL, NoSQL y el Big data.
451db_map_06.13
Ref: https://blogs.the451group.com/information_management/files/2013/06/451db_map_06.13.jpg

Categories
General Hybrid Clouds Interoperability

Cloud Service Brokers (CSB) – 1a entrega

El establecimiento de relaciones con múltiples proveedores de la nube puede ser desalentador. Incluso después de que se establecen las relaciones, todavía es necesario realizar integraciones con diversas tecnologías de los proveedores.
cloud-broker
A día de hoy, existen diferentes iniciativas que vamos a ir explorando desde Cloudadmins mediante una nueva serie de POSTS. Hoy repasaremos tres soluciones de software libre que se alinean a este modelo de agregación de servicios cloud en la capa de infraestructura, el primero con una orientación “middleware”, el segundo enfocado a capas de servicio y el último alineado a dar soluciones en el almacenamiento de grandes volumenes de datos :

DeltaCloud

http://deltacloud.apache.org/index.html
Proyecto open source desarrollado por RedHat y la fundación Apache orientado a desarrollar un conjunto de aplicaciones, scripts y herramientas para la nube. Cada cloud particular en deltaCloud es manejado a través de un adaptador (“driver”). Soporta las siguientes plataformas cloud: Amazon EC2, Fujitsu Global Cloud Platform, GoGrid, openNebula, RackSpace, RHEV-M, RimuHosting, Terremark, Vmware vCloud, Eucalyptus, IBM smartCloud, openStack, ArubaCloud y DigitalOcean
Permite crear y eliminar instancias, detenerlas, volver a arrancarlas y reiniciarlas. Además permite listar todos los perfiles de hardware, detalles sobre las instancias, etc…
Más información sobre los drivers de DeltaCloud en
http://deltacloud.apache.org/drivers.html#drivers

CompatibleOne

CompatibleOne ofrece un único lenguaje para la descripción y administración de un ilimitado numero de proveedores de servicios cloud. La arquitectura de servicios flexible de CompatibleOne hace que la descripción y creación de los diferentes cloud sea independiente del proveedor de servicios cloud escogido (OpenStack, OpenNebula, Azure, Vcloud…) y puede abordar cualquier tipo de servicio (IaaS, PaaS, SaaS, Xaas, Bpaas, …) y cualquier tipo de despliegue de servicios cloud (público, privado, híbrido, …).
El paquete de la plataforma Accords para CentOS / Fedora / RedHat puede encontrarse en build.opensuse.org. Para Debian y Ubuntu (10.10 → 12.04) está disponible en compatibleone.org/debian/
Podemos resumir su funcionamiento (y arquitectura) a grandes rasgos como:
→ Manejo de los requisitos del usuario
→ Validación y plan de aprovisionamiento
→ Ejecución del plan de aprovisionamiento
→ Entrega de los servicios del cloud

DuraCloud

https://wiki.duraspace.org/display/DURACLOUD/DuraCloud
DuraCloud es un software de gestion de servicios que permite a organizaciones archivar contenido a través de multiples gestores de cloud. Es un proyecto open source bajo licencia apache con una comunidad de usuarios y desarrolladores que crean y comparten nuevas herramientas todo el tiempo.
Principalmente, la interfaz del usuario consiste en una serie de aplicaciones web que ofrecen tres funciones generales:
→ Gestión de almacenamiento
→ Gestión de servicios
→ Interfaz para navegar entre los diferentes gestores
Pues hasta aquí hemos visto diferentes iniciativas opensource en el ámbito del brokering, en la próxima entrega repasaremos aproximaciones similares basadas en soluciones comerciales.
Buen vuelo,
Cloudadmin

Categories
In detail OpenSource Security

OpenvSwitch y OpenNebula – 3a entrega

openvswitch
opennebula_logo
Siguiendo con la serie de posts sobre OpenvSwitch y OpenNebula en los que vamos viendo la integración de OpenNebula con Open vSwitch a través del driver, vamos a ver en esta última entrega cómo se aplica el control de MAC-Spoofing en openNebula y cómo añadir también control para IP-Spoofing que por defecto no viene en el driver de OpenNebula.

MAC-Spoofing

En caso de que una máquina se cambie la MAC, sabemos que se puede hacer un ataque de man-in-the-middle entre otros problemas derivados, para evitar esto OpenNebula añade una regla al Open vSwitch para fijar la MAC, el comando que se ejecuta és de la siguiente forma, donde <mac> es la MAC asignada por OpenNebula a la máquina virtual y <puerto> es el puerto que se ha creado sobre el bridge de OpenvSwitch:

# ovs-ofctl add-flow br32 in_port=<port>,dl_src=<mac>,priority=40000,actions=normal
# ovs-ofctl add-flow br32 in_port=<port>,priority=39000,actions=drop

Los comandos anteriores lo que hacen es filtrar todo el tráfico por defecto en el puerto (prioridad 39000) y sólo dejar pasar el tráfico por el puerto que tenga la mac de la máquina virtual cómo destino/origen (prioridad 40000). Más prioridad indica que en caso de hacer match se ejecutará esta y no pasara a las siguientes.
En primer lugar vamos a probar que efectivamente si cambiamos la MAC de una máquina virtual el tráfico hacia esta es descartado . Hacemos dos máquinas virtuales con la IP 192.168.2.29 y 192.168.2.31 situadas en el mismo host físico , y cambiamos la MAC de la segunda con el macchanger :

# macchanger -r eth1

Seguidamente hacemos un ping entre las dos redes y vemos como efectivamente no llegan tanto los pings de la primera a la segunda como los de la segunda a la primera .
También hacemos un tcpdump en la segunda mientras hacemos el ping:

20:15:10.946400 ARP, Request who-has 192.168.2.31 tell 192.168.2.29, length 46
20:15:10.946409 ARP, Reply 192.168.2.31 is-at 10:c7:43:8a:dc:8d, length 28

Vemos como los broadcast de petición who-has si que nos llegan ya que estos no tienen ninguna MAC de destino asociada, pero al contestar la segunda máquina los paquetes son descartados y el mensaje anterior se repite ya que la primera máquina va repitiendo al no encontrar ninguna máquina que conteste con su MAC a la petición .
Si después de hacer el ping ejecutamos en la primera máquina lo siguiente:

# arp- a

Nos da la siguiente salida :

? (192.168.2.31) at <incomplete> on eth1

Lo cual nos confirma que los paquetes de respuesta de la IP en la petición ARP no está llegando a la primera máquina .
Vamos a hacer la misma prueba borrando las reglas de Open vSwitch que no permiten el tráfico más que en la MAC asignada , ejecutamos los siguientes comandos en la máquina física:

ovs-ofctl del-flows <bridge> dl_src=<mac>
ovs-ofctl del-flows <bridge> in_port=<port>

donde <bridge> es el bridge sobre el que estamos poniendo las máquinas virtuales , <mac> es la MAC inicial de la segunda máquina y <puerto> es el puerto virtual sobre el que se ha creado la máquina virtual en el bridge .
Ahora hacemos un ping desde la primera a la segunda y viceversa y vemos cómo efectivamente llegan los pings después de haber falseado la MAC de la segunda . Si miramos la tabla ARP de la primera máquina :

# arp- a

Vemos lo siguiente:

? (192.168.2.31) at 10:c7:43:8a:dc:8d [ether] on eth1

Así pues vemos como efectivamente la máquina está viendo la MAC falseada.
En este apartado tan sólo hemos comprovado que efectivamente funciona el control de MAC-Spoofing en OpenNebula, en el próximo apartado vamos a ver cómo OpenNebula no tiene implementado el control de IP-Spoofing y como implementar éste.

IP-Spoofing

Si cambiamos la IP a una máquina con OpenNebula veremos cómo efectivamente és possible falsear las IPs que OpenNebula assigna a nuestra máquina virtual. Los comandos vistos en el anterior apartado para que no sea posible hacer MAC-Spoofing són los siguientes:

# ovs-ofctl add-flow <bridge> in_port=<port>,dl_src=<mac>,priority=40000,actions=normal
# ovs-ofctl add-flow <bridge> in_port=<port>,priority=39000,actions=drop

Los comandos que se ejecutan para añadir los filtros, cómo vimos en la segunda entrega:

# ovs-ofctl add-flow <bridge> tcp,dl_dst=<mac>,tp_dst=<port>/<mask>,dl_vlan=<vlan>,actions=drop

y para añadir el filtro icmp:

ovs-ofctl add-flow <bridge> icmp,dl_dst=<mac>,dl_vlan=<vlan>,actions=drop

Vemos pues que no se está aplicando ningún filtro si la IP no corresponde a la que se ha definido, también hemos visto ya en el apartado anterior cómo el segundo comando del primer bloque nos filtra todo el tráfico que pase por la puerto virtual asignado a la máquina virtual , pero con una prioridad menor a la primera, que lo que hace es dejar pasar el tráfico del puerto en cuestión que coincida con la MAC de la máquina virtual.
Para el fin de que en el primer comando se filtre también lo que no coincida con la IP , necesitamos añadir el tag nw_src=<ip> , pero para añadirlo open vswitch nos obliga definir el protocolo cómo IP, ya que por ejemplo con el protocolo ARP no tiene sentido, para definir el protocolo como IP lo haremos añadiendo dl_type=0x0800
Así pues el primer comando queda de la siguiente forma:

# ovs-ofctl add-flow <bridge> dl_type=0x0800,in_port=<port_virtual>,dl_src=<mac>,nw_src=<ip>,priority=40000,actions=normal

Con este comando, pero vemos que mientras antes se dejava pasar el tráfico ARP, ahora no se está permitiendo, así pues necesitamos añadir una nueva regla que deje pasar el tráfico ARP para la MAC correspondiente. Para especificar el tráfico ARP se hace con dl_type=0x0806. Así pues, la regla quedará de la siguiente forma:

# ovs-ofctl add-flow <bridge> dl_type=0x0806,dl_src=<mac>,in_port=<port_virtual>,priority=40000,actions=normal

Una vez aplicada la regla se ha probado y funciona correctamente el control de IP-Spoofing.
Con este post terminamos la serie de Open vSwitch y OpenNebula. Para bajar el driver entero, se puede bajar de aqui.
Un saludo des del cloud! 😉