P2PWEB: un modelo de convergencia entre tecnologías Grid y P2P

1. P2PWEB: un modelo de convergencia entre tecnologías Grid y P2P Pedro García López Universitat Rovira i Virgili pedro.garcia@urv.cat

2. Indice • Introducción • Presentación del grupo • Motivación y antecedentes: P2P • Middleware P2P • Middleware deobjetos remotos (Dermi) • Middleware decomponentes distribuidos (p2pCM) • Structured overlay Networks Application Platform (Snap) • Arquitectura P2PWEB • Conclusiones y trabajo futuro

3. Introducción Grupo de Arquitecturas y Servicios Telemáticos (URV) Tópicos de Investigación: Sistemas Distribuidos Redes peer-to-peer (P2P) Middleware Trabajo en grupo (CSCW) Proyectos de Investigación: POPEYE: Peer-to-Peer Collaborative Working Environments over Mobile Ad-Hoc Networkls P2PGRID: Self-adjusting peer-to-peer and Grid Systems

4. 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)

5. Motivación: ¿ por qué P2P ? Para ofrecer servicios no disponibles en Internet: Descubrimiento de servicios ANYCAST (IP ANYCAST?) Comunicación 1-N, N-M (IP Multicast?) Federaciones, Grids, …

6. Motivación: ¿ por qué P2P ?

7. Modelos de arquitectura Centralizados (Napster) Descentralizados No estructurados (Gnutella) Estructurados (Chord) Jerárquicos (DNS) Híbridos (EDonkey, Skype)

8. Investigación en P2P: DHTs Tabla hash lookup (key) → data insert (key, data) 0 x 1 2 y z key funcion hash pos 3 “Beatles” 2 ... h(key)%N N-1 bucket hash 0 lookup (key) → data insert (key, data) 1 2 key funcion hash pos “Beatles” 2 ... h(key)%N N-1 nodo • ¿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

9. DHTs: Chord lookup(K54) N8+1 N14 N8+2 N14 • 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 m=6 N8+4 N14 2m-1 0 N8+8 N21 N1 N8+16 N32 N8+32 N42 N56 N8 K54 +1 +2 N51 +4 N14 N48 +8 +16 +32 N42 N21 N38

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

11. 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.

12. 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] …

13. 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 !

14. 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

15. Propuesta de Middleware de Área ExtensaCapa 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.

16. Propuesta de Middleware de Área ExtensaCapa de Objetos Remotos • 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

17. Propuesta de Middleware de Área ExtensaCapa de Objetos Remotos • 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

18. 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

19. 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

20. 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 cargay activación de objetos de DERMI

21. Validación: PlanetLab PlanetLab Worldwide Network 828 nodos en 409 sites Servidores Linux Otro modelo: Grid5000

22. 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)

23. 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.

24. 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)

25. 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

26. 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

27. 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

28. 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

29. Muchas gracias ! • Pedro García López • pedro.garcia@urv.cat • http://deim.urv.cat/~pgarcia • Departament d’Enginyeria Informàtica i Matemàtiques • Universitat Rovira i Virgili