p2pweb: un modelo de convergencia entre tecnologías grid y p2p

Jornadas Técnicas RedIRIS 2007

P2PWEB: un modelo de convergencia entre

tecnologías Grid y P2P

Pedro García LópezUniversitat Rovira i Virgili

[email protected]


Indice

• Introducción – Presentación del grupo

– Motivación y antecedentes: P2P

• Middleware P2P– Middleware de objetos remotos (Dermi)

– Middleware de componentes distribuidos (p2pCM)

– Structured overlay Networks Application Platform (Snap)

• Arquitectura P2PWEB• Conclusiones y trabajo futuro


Introducción

Grupo de Arquitecturas y Servicios Telemáticos (URV)

Tópicos de Investigación:Sistemas Distribuidos

Redes peer-to-peer (P2P)MiddlewareTrabajo en grupo (CSCW)

Proyectos de Investigación:POPEYE: Peer-to-Peer Collaborative Working Environments over Mobile Ad-Hoc NetworklsP2PGRID: Self-adjusting peer-to-peer and Grid Systems


Motivación: ¿ por qué P2P ?

• P2P ≠ File Sharing (eMule)• Razones:

– Escalabilidad ?

– Descentralización

– Coste

– Aprovechar recursos en los extremos de la red (datos, CPU, ancho de banda)



• Para ofrecer servicios no disponibles en Internet:– Descubrimiento de servicios

– ANYCAST (IP ANYCAST?)

– Comunicación 1-N, N-M (IP Multicast?)

– Federaciones, Grids, …


Modelos de arquitectura

• Centralizados (Napster)• Descentralizados

– No estructurados (Gnutella)

– Estructurados (Chord)

• Jerárquicos (DNS)• Híbridos (EDonkey, Skype)


Investigación en P2P: DHTs

• ¿Por qué no utilizar tablas de hash ?• Una tabla de hash asocia datos con

claves– Se hace hash de la clave para encontrar

bucket en tabla de hash– Cada bucket espera contener

#elems/#buckets elementos• En una Tabla de Hash Distribuida

(DHT), los nodos son los buckets de hash

– Se hace hash de la clave para encontrar el nodo responsable

– Datos y carga se balancean entre los nodos

key pos

00

funcion hashfuncion hash

11

22

N-1N-1

33...

xx

yy zz

lookuplookup (key) → datainsert (key, data)lookuplookup (key) → datainsert (key, data)

““Beatles”Beatles” 22

Tabla hash

bucket hash

h(key)%Nh(key)%N

0

1

2

...

nodo

key posfuncion hashfuncion hash

lookuplookup (key) → datainsert (key, data)lookuplookup (key) → datainsert (key, data)

““Beatles”Beatles” 22h(key)%Nh(key)%N

N-1


DHTs: Chord

• Ejemplo de sustrato KBR: Chord– Cada nodo conoce otros m nodos del

anillo• Sucesores: finger i de n apunta al

nodo a n+2i (o sucesor)• Predecesor (para mantenimiento del

anillo)• O(log N) estado por nodo

– Lookup se consigue siguiendo los fingers precedentes más cercanos, después sucesor

• O(log N) saltos– Necesario protocolo de estabilización

para mantener fingers actualizados

N1

N8

N14

N21

N38

N42

N48

N51

N56

m=6m=6

K54

2m-1 0

N8+1

N8+2

N8+4

N8+8

N8+16

N8+32

N14

N14

N14

N21

N32

N42

+32

+16 +8

+4

+2

+1lookup(K54)


Proximidad en red

Nodos cercanos en el overlay no están próximos en la red Internet

Nodos cercanos en el overlay no están próximos en la red Internet


FreePastry

• Es una red P2P estructurada creada en la Universidad de Rice

• Es un proyecto de código abierto desarrollado en Java

• Es una red P2P que tiene en cuenta la proximidad en red (Topology aware)

• Ofrece servicios de DHT (PAST), Application Level Multicast (Scribe) y ANYCAST entre otros.


Aplicaciones sobre DHTs

• File sharing [CFS, OceanStore, PAST, …]• Web cache [Squirrel, Coral]• Censor-resistant stores [Eternity, FreeNet, …]• Application-layer multicast [Scribe, Narada, …]• Event notification [Scribe]• Streaming (SplitStream)• Naming systems [ChordDNS, INS, …]• Query and indexing [Kademlia, …]• Communication primitives [I3, …]• Backup store [HiveNet]• Web archive [Herodotus]• …


Middleware P2P

• Faltan herramientas y middleware para construir aplicaciones escalables de ámbito Internet

• Hay que considerar aspectos como la tolerancia a fallos, la escalabilidad, el balanceo de carga, la alta disponibilidad, ,la proximidad en red y la auto-organización entre otros

• Se necesitan nuevas abstracciones !


Propuesta de Middleware de Área Extensa

Definición de un middleware de objetos distribuidos (Dermi) basado en eventos– Definición de nuevas abstracciones de invocación– Definición de un servicio de localización descentralizada de

objetos– Definición de un servicio de intercepción distribuída– Definición de un servicio de balanceo de carga


Propuesta de Middleware de Área Extensa Capa de Objetos Remotos

• Abstracciones de invocación uno-a-uno– Son llamadas donde un objeto cliente llama remotamente un

método de un objeto servidor.– Llamadas directas

• Mensaje de la llamada en un único salto de cliente a servidor.

– Llamadas hopped (Key Based Routing!!)• Localizador de objeto remoto: p2p://objectID • Mensaje de la llamada enrutado por la red de cliente a un

posible servidor.• Más tolerante a fallos.



• Abstracciones de invocación uno-a-muchos– Application Level Multicast!.– Llamadas multicall

• Son llamadas de un objeto cliente a múltiples servidores o viceversa.

– Llamadas anycall• Permite hacer una llamada al objeto servidor más

cercano al cliente, en términos de proximidad de la red.

– Llamadas manycall• Parecido al anycall, pero en este caso la llamada tiene

que ser satisfecha por varios miembros del grupo.

MULTICAST

ANYCAST

MANYCAST



• Hemos validado Dermi por medio de medidas experimentales en la red PlanetLab

• Inspirado en Java RMI (dynamic proxies)• Se demuestra que la sobrecarga introducida por las llamadas a través

del middleware es aceptable• Resultados:

– Llamada directa síncrona: overhead < 14%

– Llamada multicall: speedup ≈ 3.3

– Llamada anycall: speedup ≈ 1.2

– Llamada manycall: speedup ≈ 1.2


Hacia el P2PWEB: SNAP

• ¿Qué es Snap?– Structured overlay Networks Application Platform

• Sirve de prueba de concepto para nuestra arquitectura• Framework de despliegue de aplicaciones web JavaEE

sobre redes P2P• Intentar proporcionar una transición lo menos compleja

posible de aplicaciones JavaEE cliente/servidor a entornos p2p

• Proyecto del OW2 Consortium– http://snap.objectweb.org


Aplicaciones de nuestro middlewareSnap

• Servicios Snap– Despliegue descentralizado y seguro de aplicaciones

web• Única fase centralizada: garantizar que sólo los

administradores de la plataforma pueden instalar, desplegar y monitorizar aplicaciones de la red Snap

• Uso del servicio de nombres de Dermi + PKI

– Activación de aplicaciones web bajo demanda• Si es la primera instancia, se activa en local• En caso contrario, vía DERMI (anycall) se nos

redirige automáticamente a la instancia más cercana• Uso del servicio de activación de objetos +

abstracciones invocación Dermi


Aplicaciones de nuestro middlewareSnap

• Servicios Snap– Servicio de localización de aplicaciones web

• Mediante el uso de identificadores propios (p2p://deskshot.urv.net), podemos encontrar recursos en una red Snap

– Servicio de adaptación y balanceo de carga• Automáticamente se crean pequeños clusters dónde se replica la

instancia de aplicación web (aplicación + base de datos, etc)• Uso de los servicios de balanceo de carga y activación de objetos

de DERMI


Validación: PlanetLab

• PlanetLab Worldwide Network• 828 nodos en 409 sites• Servidores Linux• Otro modelo: Grid5000


P2PWEB

• Dos direcciones de convergencia entre P2P y Web:– Utilizar redes P2P (ordenadores personales) para ofrecer

aplicaciones y servicios Web: p2p Web hosting (IBM YouServ), p2p content distribution networks (CORAL), J2EE p2p deployment (SNAP), Backup Storage (PeerStore), …

– Crear redes P2P (federaciones) de servidores estables que ofrezcan servicios de ámbito Internet (Wide area): Content distribution networks (Akamai), federated libraries (MIT DSpace), publish/subscribe (NaradaBrokering), learning repositories (FIRE), library preservation and data archival (LOCKSS, SAV)


Modelo P2PWEB

• La idea clave es interconectar una red masiva de servidores Web usando una red P2P (DHT) que se comunique mediante HTTP.

• Una plataforma P2PWEB podía ofrecer diferentes servicios de ámbito Internet como distribución de contenidos, búsqueda distribuida o identificación distribuida entre otros.

• Consideramos que las DHTs son especialmente adecuadas para interconectar estas federaciones masivas de servidores.


P2PWEB y DHTs

• ¿ Por qué DHTs ?– Churn vs Stability– NAT traversal & firewalls vs accessibility – Persistent connections vs decoupling– Peers & SuperPeers

• La red descentralizada de servidores Web construiría un overlay de super-peers que podrían ofrecer servicios añadidos a los peers (browsers)


Arquitectura P2PWEB

• Estamos implementando un prototipo del modelo P2PWEB sober nuestro propio DHT jerárquico (Cyclone, IEEE P2P). El DHT jerárquico permite:– Clustering: para agrupar nodos siguiendo algun criterio

(geoclusters, proximity clusters)– Localidad de contenidos: permite a las aplicaciones

almacenar información en clusters específicos – Localidad de rutas: podemos enrutar en clusters locales de

una organización sin afectar al resto. – Caching local permite hacer caching en cluster s locales


Arquitectura: HSymphony

• Hemos implementado la versión jerárquica del DHT siguiendo nuestro DHT Cyclone (IEEE P2P2005).

• H-Symphony está implementado en PHP5 y MySQL.• H-Symphony se ha probado:

– Mediante simulación (16 K nodos)– Experimentación con 300 nodos en LAN– Ahora estamso probandolo en servidores Web distribuidos en

Internet• La red H-Symphony es segura (controlled bootstraping)

usando PKI y certificados


Prueba de Concepto: MoodleShare

• Moodle es una herramienta de campus virtual desarrollada en PHP.

• Existen más de 17.000 servidores Moodle en el mundo.• MoodleShare conectaría a todos en una red P2P con mínimo

overhead – Es una red desacoplada, no hay conexiones entre nodos– La tabla de vecinos es una lista de URLs

• Servicios de Moodle Share:– Moodle Sites and Statistics descentralizado– Información geográfica– Moodle Search: búsqueda de contenidos


Conclusiones

• Hemos presentado la posible convergencia entre modelos Web y P2P

• Creemos que las DHTs son una plataforma ideal para este problema.

• Presentamos diferentes resultados concretos: DERMI, SNAP, H-Symphony, MoodleShare

• En el contexto del proyecto P2PGRID con la UPC y la Universidad de Navarra, continuamos investigando en sistemas descentralizados de gran escala


Muchas gracias !

Pedro García Ló[email protected]

http://deim.urv.cat/~pgarciaDepartament d’Enginyeria Informàtica i Matemàtiques

Universitat Rovira i Virgili

p2pweb: un modelo de convergencia entre tecnologías grid y p2p

Documents