1 / 57

Dong Lu Committee Peter A. Dinda (Chair) Fabian E. Bustamante

A Decentralized Relational Information Service for Large Scale Distributed Computing Thesis Proposal April 2 nd , 2004. Dong Lu Committee Peter A. Dinda (Chair) Fabian E. Bustamante Yan Chen Ian Foster (UC and ANL). What is information service?.

rance
Download Presentation

Dong Lu Committee Peter A. Dinda (Chair) Fabian E. Bustamante

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Decentralized Relational Information Service for Large Scale Distributed ComputingThesis ProposalApril 2nd, 2004 Dong Lu Committee Peter A. Dinda (Chair) Fabian E. Bustamante Yan Chen Ian Foster (UC and ANL)

  2. What is information service? • An information service stores information about the resources and services in a distributed computing environment and answer queries about it. • GIS is information service for Grid computing. MDS2 is an example of GIS

  3. What is RGIS? • RGIS: Relational Grid Information Service • RGIS is a decentralized relational information service that is being built on top of distributed and replicated relational data model

  4. Why RGIS? • RGIS can answer complex compositional queries • Relational algebra (SQL) • Joins • Difficult in a hierarchical model (directory service) • Other reasons • Indexes separate from data model • Schema evolution • Transactional insert/update/delete • Consistency

  5. Example Queries and Updates • “Find me four Xeon machines with a total of 8 GB of RAM within 5 seconds” • “Inform all my friends that the machine dualsword now has 2 GB of RAM within 500 seconds”

  6. Thesis Statement • A centralized relational information server, such as our current RGIS system, can’t scale with the distributed computing environment. How can we build a scalable distributed relational information service with query and update constraints? We have addressed query constraints by developing query techniques on individual servers to trade off the query time with the size of the result set.  We have developed infrastructure for RGIS to support replication through update push.  I propose to address update constraints, namely bounds on replica staleness. This will be built on the basis of predictive techniques for statistical quality of service (QoS) for single and parallel end-to-end TCP transfers.

  7. Related works • MDS2: OpenLDAP based information service. Part of the globus tool kit • R-GMA: Another relational data model for GIS that focused on dynamic properties of resources • MatchMaker: classified advertisements (classads), part of the condor system • Redline: A language that enables the definition of Constraint Satisfaction Problems (CSP) and then apply heuristics to solve the NP-hard CSP problems • etc.

  8. Outline • Motivation • Challenges • System Architecture • GridG for query evaluation • Query techniques on a single server • Providing statistical QoS to data transfers on the Internet • Update Consistency Constraint • Schedule

  9. Motivation to build a distributed information service • A centralized server can’t scale with a distributed system and number of users • CPU, memory and disk can easily become performance bottleneck • Even if we host the service using a high performance cluster, the outgoing bandwidth can easily become performance bottleneck

  10. Thesis Challenges • Complex queries sometimes take a long time to finish • We have proposed and implemented scoped, approximate and nondeterministic query techniques to address this challenge • We have evaluated them using GridG • How to maintain proper consistency among the replicated databases? • I am proposing to maintain soft real-time bounded weak consistency among the servers This Challenge Has Been Addressed

  11. Thesis Challenges • How to bound the weak consistency with real time? • I am proposing to monitor the overlay links to provide soft QoS to data transfer and then send updates to other replicas so that the consistency can be time bounded • How to provide soft statistical QoS to data transfer on the Internet? (TCP) • I am proposing to develop a novel TCP throughput benchmarking technique and then build statistical QoS on the basis of prediction

  12. Outline • Motivation • Challenges • System Architecture • GridG for query evaluation • Query techniques on a single server • Providing statistical QoS to data transfers on the Internet • Update Consistency Constraint • Schedule

  13. RGIS Model of a Grid module Software • Annotated network topology graph • Annotation examples • Hosts: memory, disk, OS, NICs, etc. • Router/Switch: backplane bandwidth, ports • Link: latency and bandwidth • Virtualization, Futures, Leases • Virtual machines endpoint router iplink host Network Data link maclink macswitch Physical [SC03-1] connectorswitch connectorlink

  14. RGIS Architecture Developers: Lu, Dinda, Weinrich, Lange [SC03-1]

  15. RGIS Design (Intersite) B A Update Push To Friend Site RGIS Server RGIS Server Update Push To Friend Site • Site RGIS server pushes local updates to friend sites • Site RGIS server consolidates updates from site and friend sites • Site RGIS server answers all queries originating from its site C RGIS Server

  16. Outline • Motivation • Challenges • System Architecture • GridG for query evaluation • Query techniques on a single server • Providing statistical QoS to data transfers on the Internet • Update Consistency Constraint Control • Schedule

  17. GridG: A Synthetic Grid Generator • Why GridG? • Evaluation of RGIS query performance; distributed systems simulation, etc.. • Output: Network topology annotated with the hardware and software on each node and link • Layer 3 network: hosts, routers, links • Hosts: memory, architecture, number of CPUs, disk, operating system, vendor, clock rate • Routers: switching capacity • Links: bandwidth and Latency [SC03-2, SIGMETRICS PER]

  18. Related work: current graph generators • Random: Waxman, etc. • Hierarchical : Tiers, Transit-Stub, etc. • Degree-based: Inet, Brite, etc. • GridG is the first topology generator that has a clear three-level hierarchy and also follows power law of Internet topology • GridG is the first generator that can annotate the hosts, routers and links with reasonable properties

  19. Quick review of the Power laws of Internet topology

  20. GridG Example Router (switching capacity) Link (bw, latency) Host (arch, numcpu, clock rate, osvendor, mem, disk)

  21. Requirements for GridG • Realistic topologies • Connected • Hierarchical structure • Power laws of Internet topology • Realistic annotations • Distributions of attributes • Correlations of attributes • Intra-host • Inter-host

  22. GridG architecture • A sequence of transformations on a text-based representation of an annotated graph.

  23. Topology generation (Published on ACM Sigmetrics Performance Evaluation Review) • GridG follows the power laws and has a clear three level hierarchical structure • We propose the following as the relationships among Internet topology power laws New rank law Outdegree power law Eigenvalue law

  24. Graph annotation (Complete GridG paper published on SC’03) Assumed Dependence Tree The dependence tree is transformed into conditional probability in the implementation of GridG

  25. GridG V1.0 release • http://www.cs.northwestern.edu/urgis/GridG

  26. Outline • Motivation • Challenges • System Architecture • GridG for query evaluation • Query techniques on a single server • Providing statistical QoS to data transfers on the Internet • Update Consistency Constraint • Schedule

  27. SQL Example of Cluster Finder Query SELECT [scoped-approx] h1.distip, h2.distip FROM hosts h1, hosts h2, iplinks l1, iplinks l2, routers r WHERE h1.mem_mb+h2.mem_mb>=1024 and h1.os='linux' and h2.os='linux' and ((l1.src=r.distip and l2.src=r.distip and l1.dest=h1.distip and l2.dest=h2.distip) or (l1.dest=r.distip and l2.dest=r.distip and l1.src=h1.distip and l2.src=h2.distip)) and h1.distip<>h2.distip and L1.BW_MBS >= 100 AND L2.BW_MBS >= 100 [SCOPED BY r.distip=X] WITHIN 100 seconds;

  28. Scoped and Approximate query techniques (published on 4th International workshop on Grid computing) • Scoped query: all the joins are limited to a neighborhood in the network, exploiting the network topology captured in the RGIS system. • Approximate query: the number of joins is reduced by replacing them with constraints on individual objects and the simplified query is run against the entire network.

  29. Nondeterministic query technique (Published on SC’03) • Non deterministic query: a random subset of the network objects are chosen to conduct joins • Another mechanism to trade off query time with query result set • All the three techniques, namely, non-deterministic, scoped and approximate queries can be time bounded

  30. Summary of query techniques All results Approximate results Nondeterministic results Scoped results

  31. Outline • Motivation • Challenges • System Architecture • GridG for query evaluation • Query techniques on a single server • Providing statistical QoS to data transfers on the Internet • Update Consistency Constraint • Schedule Finished work Proposed work

  32. Update Problem • “Inform my friends that the machine dualsword now as 2 GB of RAM within 500 seconds” • Update Push • How do I make the whole push operation run within the time bound given dynamic network conditions? Proposed work

  33. Why do we need statistical QoS for data transfers on the Internet? • To bound the data propagation time among the RGIS servers, we need soft deadline for data transfers • But reservations typically unavailable • Adapt to changing network • Parallel TCP, Overlay Multicast • Inform user when request is impossible • Statistical QoS is a soft guarantee: To meet deadline with specified high probability. It is prediction based

  34. Related works • Available bandwidth estimation: packet pair, cprobe, pathchar/pchar, nettimmer, pathload, NCS, pathrate, spruce, remos, etc. • TCP benchmarking: NWS, etc. can provide real time TCP throughput prediction However, available bandwidth differs significantly from TCP throughput that applications can achieve. However, recent research by Sudharshan et. al showed that simple TCP benchmarking can’t predict large file transfers well.

  35. Related works • Resource ReserVation Protocol: RSVP needs cooperation from routers. However, routers on a End-to-End path belong to different ISPs, thus it is hard to use in practice • Network reservation based QoS: GARA is one example. • Service Level Agreement (SLA): It is hard to make SLAs for End-to-End paths

  36. Prediction based statistical QoS for data transfers on the Internet • Main idea: predict TCP data transfer time with confidence interval • Challenges: • Simple TCP benchmarking techniques failed to predict TCP throughput for large file transfers. • Internet is dynamically changing. How can we capture the dynamics on the End-to-End path? Proposed work

  37. Observations File Size and TCP Throughput are strongly correlated Steady State Throughput

  38. Probe Pair: a new TCP benchmarking technique Proposed work Why simple TCP benchmarking fails?

  39. Experimental methodology • Purpose: To study correlation between TCP throughput and flow size, and evaluate proposed TCP benchmark mechanism • Testbed: 40 PlanetLab nodes in North America, Europe, Asia, and Australia. Repeat random pairing 3 times, 60 distinctive paths total. 2,430,000 TCP transfers • TCP Flow size: 100 KB, 200 KB, 400 KB , 600 KB, 800 KB, 1 MB, 2 MB, 4 MB, 10 MB, (up to 1GB in other experiments)

  40. Verification of Probe Pair(CDF of prediction error)

  41. Internet stability • Routing stability (Fundamental): • Paxson’s work show that Internet paths are heavily dominated by a single route • Spatial locality and temporal locality of end-to-end TCP throughput: • Balakrishnan, et al showed that nearby Internet hosts often have almost identical distributions of observed throughput to a remote web server • Balakrishnan, et al also showed that End-to-End TCP throughput are stationary on the scale of tens of minutes. And lognormal distribution can be used to model the End-to-End TCP throughput

  42. Capturing transient Internet stability • Given the strong correlation between TCP flow size and throughput, what could be the proper model for End-to-End steady state TCP throughput? • lognormal is a good model for aggregated TCP throughput on a given path, namely, throughput with different TCP flow sizes • What is the proper model for steady state TCP throughput distribution?

  43. Capturing transient Internet stability • We define Statistical Stable Region (SSR) as the length of a period of time where the ratio between maximum and minimum estimated steady state TCP throughput is less than a constant factor • With extensive Internet measurement study, we found that normal distribution can be used to model TCP throughput within each SSR

  44. Capturing transient Internet stability

  45. Capturing transient Internet stability

  46. dualPats: predicting TCP throughput with small probe pairs Proposed work We build “dynamic sampling rate adjustment algorithm” to capture the End-to-End TCP throughput dynamics and therefore to minimize probing overhead in dualPats.

  47. Parallel TCP throughput prediction • Parallel TCP is widely used in distributed computing, GridFTP is one example • How can we predict parallel TCP throughput without being intrusive to the network? Proposed work

  48. Prediction Example

  49. Outline • Motivation • Challenges • System Architecture • GridG for query evaluation • Query techniques on a single server • Providing statistical QoS to data transfers on the Internet • Update Consistency Constraint • Schedule

  50. Related works • Strong consistency: a correctness criteria for traditional replicated transactional databases • Weak consistency: examples of distributed systems that greatly favor performance over consistency include Coda, Bayou, etc.. There is no bound on inconsistency in such systems • TACT is a distributed system with adjustable consistency bounds among the replicas. But the TACT system focused on logical time bounds

More Related