From Parallel Virtual Machine to Virtual Parallel Machine: The Unibus System

Transcription

1 From Parallel Virtual Machine to Virtual Parallel Machine: The Unibus System Vaidy Sunderam Emory University, Atlanta, USA

2 Credits and Acknowledgements Distributed Computing Laboratory, Emory University Magda Slawinska, Jarek Slawinski, Vaidy Sunderam Collaborators Oak Ridge Labs (A. Geist, C. Engelmann) Univ. Tennessee (J. Dongarra, G. Bosilica) Sponsors U. S. Department of Energy National Science Foundation Emory University

3 Background Metacomputing research: PVM, IceT, Harness, H2O Unibus Platforms Heterogeneous along multiple dimensions Spanning administrative boundaries Pragmatics Flexible middle-level middleware Based on familiar paradigms Premise: multiple situations must be supported preferably adaptively and dynamically Goals: lightweight, reconfigurable, heterogeneous computing Aggregation and sharing Support for multiple programming models

4 PVM: Platform and Programming Historical perspective PVM 1.0, circa 1989

5 Key PVM Abstractions Programming model Timeshared, multiprogrammed virtual machine Two-level process space Functional name + ordinal number Flat, open, reliable messaging substrate Heterogeneous messages and data representation Dynamic creation of tasks and/or instances Multiprocessor emulation Processor/process decoupling Raw nodes projected Transparently Or with exposure of heterogeneous attributes Dynamic addition/deletion of processors(hosts)

6 Parallel Distributed Computing Multiprocessor systems Parallel distributed memory computing Stable and mainstream: SPMD, MPI Goals: performance, single job time to completion Platforms Applications correspondingly tightly coupled Typically no aggregation of diverse resources, no resource dynamism, and rare application dynamism But still need setup and staging initially Multicore: forcing rethink of some aspects

7 Parallel Distributed Computing Key requirements/functionality Aggregation and sharing of diverse resources Customizing resources as needed Deploy most suitable (parallel) programming model (libraries, runtime) Adapting to available/appropriate communications infrastructure Additional self-organizing properties Resilience via dynamic resource management Reduced global state Provider-provider, provider-client

8 Approach Summary Distributed component model (H2O) Resource providers supply component containers Authorized parties deploy reconfiguration components Clients assemble and use components to run applications Flexible communication substrate (RMIX, REVENTS) Components communicate using common basic paradigms (RMI, Async-RMI, distributed events) Underlying protocol stack can be tailored Dynamically select transport Present appropriate API to application e.g. Message Passing, RMI, WS Putting it all together (Unibus) Configuration, adaptation, unification

9 Resource Sharing Abstraction Providers own resources Independently make them available over the network Clients discover, locate, and utilize resources Resource sharing occurs between single provider and single client Relationships may be tailored as appropriate Including identity formats, resource allocation, compensation agreements Clients can themselves be providers Cascading pairwise relationships may be formed Network Providers Clients

10 Component Platform Resources provided as services Active software components exposing resource functionality May represent added value Run within provider s container (execution context) Dynamic deployment By any authorized party provider, client, or reseller Providers specify access policies Client identity + code signatures Support for temporal restrictions Decoupling Providers from deployers Providers from each other Provider host <<create>> Container A Provider Deploy B Traditional model Provider host <<create>> Container A Provider B H2O model Lookup & use Deploy Lookup & use Client Provider, Client, or Reseller Client

11 Example usage scenarios Registration and Discovery , UDDI JNDI LDAP DNS GIS phone, Publish Find Deploy Provider A Client Provider A native code B Deploy Client Provider Provider... A A B B Deploy Client Legacy App Repository Repository Service Reseller A C B Software Vendor A C B Resource = legacy application Provider deploys the service Provider stores the information about the service in a registry Client discovers the service Client accesses legacy application through the service Resource = computational service Reseller deploys software component into provider s container Reseller notifies the client about the offered computational service Client utilizes the service Resource = raw CPU power Client gathers application components Client deploys components into providers containers Client executes distributed application utilizing providers CPU power

12 Containers and Components Good old Unix SSH login + a.out Clouds EC2: Zone + AMI Instance Google App Engine: Sandbox + Python RTE + Webapp/CGI BlueCloud: Xen/PowerVM + Hadoop H2O/Harness container = kernel component = pluglet (remotely accessible object w. std. interfaces) Interface LUDecomp { LUDecomp( ); } Functional interfaces Pluglet Clients Pluglet Kernel [Suspendible] Interface Pluglet { void init(executioncontext cxt); void start(); void stop(); void destroy(); } Interface Suspendible { void suspend(); void resume(); } (e.g. LUDecomp)

13 RMIX communication layer Extensible RMI framework Client and provider APIs uniform access to communication capabilities Service Access supplied by pluggable provider implementations Multiple invocation protocols RMIX JRMPX RMIX XSOAP RMIX RMIX RPCX RMIX Myri JRMPX, ONC-RPC, SOAP Extended features Asynchronous calls, cancellation Stackable (e.g. compression, encryption) Java Web Services SOAP clients ONC-RPC GM

14 RMIX Protocol Stacks Interoperability SOAP / HTTP Connectivity JXTA, tunneling Security SSL, JXTA groups High performance ARPC, custom (Myrinet, Quadrics) Protocol negotiation H2O Pluglet Client or Server Internet H2O Pluglet Client or Server Security, interoperability connectivity firewall H2O Pluglet Client or Server Harness H2O Pluglet Kernel efficiency efficiency H2O Pluglet Client or Server

15 REVENTS distributed event handling REVENTS Model Topics and publishers Clients register subscriptions Channels link clients with servers to tunnel event queues Server Publishers Topics Subscriptions P1 T1 s1 s2 P2 P3 T2 s3 s4 Event Queues Client 1 Channel 1 Client 2 Channel 2 Subscribers S4 S2 S3 S1 REVENTS Library Hierarchical topics list Event = metadata + payload Filters to focus subscriptions Filter language based on SQL Event priorities, time-to-live, override filters Late subscription Initial state notification REVENTS in H2O RMIX-based event transport Blocking poll to transfer events through channels Flexible communication links: multiprotocol, security, etc. H2O Session Event Channel Broken REVENTS channel interpreted as an H2O client disconnection

16 MOCCA: CCA/H2O/RMIX Builder Service H2O Kernel Builder Pluglet Mocca Main Builder Mocca Main Builder Manage Component Pluglet Component Component Pluglet Pluglet Builder Builder Builder Builder Builder Builder CCA Component CCA Component Pluglet CCA Pluglet CCA Pluglet CCA Pluglet CCA Pluglet CCA Pluglet CCA Invoke H2O dynamic deployment runtime, remote component (un)loading H2O security multiple components may run without interfering Each component running as a separate pluglet RMIX communication efficiency, multiprotocol interoperability

17 Performance (MOCCA/H2O vs CCA/XCAT)

18 MOCCA Case Study: Gold Clusters Formation Ad-hoc sharing across grids and standalone resources On clusters, H2O kernels scheduled through queuing systems On grids, likewise, through brokers Kernels dynamically register in a naming service Simulated Cluster Formation The original simulated annealing code rewritten in CCA style Two stand-alone, SSH-enabled workstations at Cyfronet, Krakow PBS-enabled cluster at Cyfronet, Krakow European CrossGrid testbed, LCG middleware, resource broker located in LIP, Lisbon, Portugal

19 Automated Deployment So what is missing? Configuration & related tasks Automating tasks environment configuration uploading and compiling computational applications staging input data / result collection Client side: Interactive console Unified and coherent interface Resource virtualization Mediators service-drivers Provider side: Access daemons E.g. sshd, ftpd Prototype implementation FT-MPI Client side Provider side

20 ZF-MPI tasks ZF-MPI Console DVM Assembly Data Sync Add computational resources to DVM Upload FT-MPI Decompress sources Install Launch FT-MPI daemons Synchronize data, source files across DVM nodes Compile and build Invoke standard shell commands Application launch Run MPI programs

21 Prototype ZF-MPI/FT-MPI Implementation ZF-MPI Console Virtual machine assembly Data synchronization Compile and build (// execution of remote shell commands) Application launch 1 zf-mpi> add ft_mpi user1-sun@{lab6a,lab6b,lab6c,lab6d,compute} 2 zf-mpi> add ft_mpi user2-linux@{wembley,gobo,emily,sprocket} 3 zf-mpi> ft_mpi setns compute //nameserver host 4 zf-mpi> ft_mpi add ALL 5 zf-mpi> ft_mpi console conf 6 zf-mpi> sync ~/NPB3.2.1/NPB3.2-MPI ~/zf-mpi/ 7 zf-mpi> cd ~/zf-mpi/npb3.2-mpi 8 zf-mpi> make bt NPROCS=8 CLASS=B 9 zf-mpi> mv bin/bt.b.8 $HARNESS_BIN_DIR/$HARNESS_ARCH/ 10 zf-mpi> ft_mpi ftmpirun compute -np 8 -o bt.b.8 > log 11 zf-mpi> cat log grep "Time in seconds" 12 zf-mpi> ft_mpi console haltall

22 Generalizing automated deployment

23 Putting it all together: Unibus Client-side virtualization Agents and mediators Complete freedom and flexibility for providers

24 Unibus model

25 Conclusions Multi-domain resource sharing Powerful paradigm, tremendous potential Very difficult to realize: technical, non-techincal issues Our premise Provider autonomy and flexibility are crucial Clients need tailoring/reconfiguration capabilities From PVM to Unibus Dynamic remote deployment & conditioning Seamless aggregation of heterogeneous resources Client-side virtualization and unification Resource management <-> Programming model Metacomputing 2009: Virtual Parallel Machine