The Handbook of Research on Scalable Computing Technologies Kuan-Ching Li Providence University, Taiwan Ching-Hsien Hsu Chung Hua University, Taiwan Laurence Tianruo Yang St. Francis Xavier University, Canada Jack Dongarra University of Tennessee, USA Hans Zima Jet Propulsion Laboratory, California Institute of Technology, USA and University of Vienna, Austria
InformatIon scIence reference Hershey • New York
Director of Editorial Content: Senior Managing Editor: Assistant Managing Editor: Publishing Assistant: Typesetter: Cover Design: Printed at:
Kristin Klinger Jamie Snavely Carole Coulson Sean Woznicki Carole Coulson, Dan Wilson, Daniel Custer, Kait Betz Lisa Tosheff Yurchak Printing Inc.
Published in the United States of America by Information Science Reference (an imprint of IGI Global) 701 E. Chocolate Avenue Hershey PA 17033 Tel: 717-533-8845 Fax: 717-533-8661 E-mail:
[email protected] Web site: http://www.igi-global.com/reference
Copyright © 2010 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or companies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark.
Library of Congress Cataloging-in-Publication Data Handbook of research on scalable computing technologies / Kuan-Ching Li ... [et al.], editors. p. cm. Includes bibliographical references and index. Summary: "This book presents, discusses, shares ideas, results and experiences on the recent important advances and future challenges on enabling technologies for achieving higher performance"--Provided by publisher. ISBN 978-1-60566-661-7 (hardcover) -- ISBN 978-1-60566-662-4 (ebook) 1. Computational grids (Computer systems) 2. System design. 3. Parallel processing (Electronic computers) 4. Ubiquitous computing. I. Li, KuanChing. QA76.9.C58H356 2009 004--dc22 2009004402
British Cataloguing in Publication Data A Cataloguing in Publication record for this book is available from the British Library. All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the authors, but not necessarily of the publisher.
Editorial Advisory Board
Minyi Guo, The University of Aizu, Japan Timothy Shih, Tamkang University, Taiwan Ce-Kuen Shieh, National Cheng Kung University, Taiwan Liria Matsumoto Sato, University of Sao Paulo, Brazil Jeffrey Tsai, University of Illinois at Chicago, USA Chia-Hsien Wen, Providence University, Taiwan Yi Pan, Georgia State University, USA
List of Contributors
Allenotor, David / University of Manitoba, Canada ..........................................................................................471 Altmann, Jorn / Seoul National University, South Korea ..................................................................................442 Alves, C. E. R. / Universidade Sao Judas Tadeu, Brazil ....................................................................................378 Bertossi, Alan A. / University of Bologna, Italy .................................................................................................645 Buyya, Rajkumar / The University of Melbourne, Australia.....................................................................191, 517 Cáceres, E. N. / Universidade Federal de Mato Grosso do Sul, Brazil ..............................................................378 Cappello, Franck / INRIA & UIUC, France ........................................................................................................31 Chang, Jih-Sheng / National Dong Hwa University, Taiwan ................................................................................1 Chang, Ruay-Shiung / National Dong Hwa University, Taiwan ...........................................................................1 Chen, Jinjun / Swinburne University of Technologies, Australia.......................................................................396 Chen, Zizhong / Colorado School of Mines, USA ..............................................................................................760 Chiang, Kuo / National Taiwan University, Taiwan .............................................................................................. 123 Chiang, Shang-Feng / National Taiwan University, Taiwan ................................................................................ 123 Chiu, Kenneth / University at Binghamtom, State University of NY, USA ........................................................471 Dai, Yuan-Shun / University of Electronics Science Technology of China, China & University of Tennessee, Knoxville, USA .........................................................................................................219 de Assunção, Marcos Dias / The University of Melbourne, Australia ..............................................................517 de Mello, Rodrigo Fernandes / University of São Paulo – ICMC, Brazil.........................................................338 Dehne, F. / Carleton University, Canada ............................................................................................................378 Dodonov, Evgueni / University of São Paulo – ICMC, Brazil ...........................................................................338 Dongarra, Jack / University of Tennessee, Knoxville, USA; Oak Ridge National Laboratory, USA; & University of Manchester, UK ..........................................................................................................................219 Doolan, Daniel C. / Robert Gordon University, UK ...........................................................................................705 Dou, Wanchun / Nanjing University, P. R. China .............................................................................................396 Dümmler, Jörg / Chemnitz University of Technology,Germany .........................................................................246 Eskicioglu, Rasit / University of Manitoba, Canada ..........................................................................................486 Fahringer, Thomas / University of Innsbruck, Austria ........................................................................................89 Fedak, Gilles / LIP/INRIA, France .......................................................................................................................31 Ferm, Tore / Sydney University, Australia ..........................................................................................................354 Gabriel, Edgar / University of Houston, USA ....................................................................................................583 Gaudiot, Jean-Luc / University of California, Irvine, USA ...............................................................................552 Gentzsch, Wolfgang / EU Project DEISA and Board of Directors of the Open Grid Forum, Germany .............62 Graham, Peter / University of Manitoba, Canada .............................................................................................486 Grigg, Alan / Loughborough University, UK ......................................................................................................606 Grigoras, Dan / University College Cork, Ireland .............................................................................................705 Guan, Lin / Loughborough University, UK ........................................................................................................606 Gunturu, Sudha / Oklahoma State University, USA ..........................................................................................841 Guo, Minyi / Shanghai Jiao Tong University, China ..........................................................................................421
Gupta, Phalguni / Indian Institute of Technology Kanpur, India .......................................................................645 He, Xiangjian / University of Technology, Sydney (UTS), Australia ..........................................................739, 808 Jang, Yong J. / Yonsei University, Seoul, Korea .................................................................................................276 Ji, Yanqing / Gonzaga University, USA ..............................................................................................................874 Jiang, Hai / Arkansas State University, USA ......................................................................................................874 Jiang, Hong / University of Nebraska–Lincoln, USA .........................................................................................785 Kondo, Derrick / ENSIMAG - antenne de Montbonnot, France..........................................................................31 Lam, King Tin / The University of Hong Kong, Hong Kong .............................................................................658 Li, Xiaobin / Intel® Corporation, USA ..............................................................................................................552 Li, Xiaolin / Oklahoma State University, USA ....................................................................................................841 Liu, Chen / Florida International University, USA ............................................................................................552 Liu, Shaoshan / University of California, Irvine, USA.......................................................................................552 Malécot, Paul / Université Paris-Sud, France ......................................................................................................31 Malyshkin, V.E. / Russian Academy of Science, Russia .....................................................................................295 March, Verdi / National University of Singapore, Singapore ............................................................................140 Mihailescu, Marian / National University of Singapore, Singapore..................................................................140 Nadeem, Farrukh / University of Innsbruck, Austria ..........................................................................................89 Nanda, Priyadarsi / University of Technology, Sydney (UTS), Australia ..........................................................739 Oh, Doohwan / Yonsei University, Seoul, Korea ................................................................................................276 Ou, Zhonghong / University of Oulu, Finland ...................................................................................................682 Parashar, Manish / Rutgers, The State University of New Jersey, USA ..............................................................14 Pierson, Jean-Marc / Paul Sabatier University, France ......................................................................................14 Pinotti, M. Cristina / University of Perugia, Italy .............................................................................................645 Prodan, Radu / University of Innsbruck, Austria .................................................................................................89 Quan, Dang Minh / International University in Germany, Germany ................................................................442 Ranjan, Rajiv / The University of Melbourne, Australia ..................................................................................191 Rauber, Thomas / University Bayreuth, Germany .............................................................................................246 Rautiainen, Mika / University of Oulu, Finland ................................................................................................682 Rezmerita, Ala / Université Paris-Sud, France ....................................................................................................31 Rizzi, Romeo / University of Udine, Italy ...........................................................................................................645 Ro, Won W. / Yonsei University, Seoul, Korea....................................................................................................276 Rünger, Gudula / Chemnitz University of Technology,Germany .......................................................................246 Shen, Haiying / University of Arkansas, USA ....................................................................................................163 Shen, Wei / University of Cincinnati, USA .........................................................................................................718 Shorfuzzaman, Mohammad / University of Manitoba, Canada.......................................................................486 Song, S. W. / Universidade de Sao Paulo, Brazil................................................................................................378 Sun, Junzhao / University of Oulu, Finland .......................................................................................................682 Tabirca, Sabin / University College Cork, Ireland .............................................................................................705 Tang, Feilong / Shanghai Jiao Tong University, China ......................................................................................421 Teo, Yong Meng / National University of Singapore, Singapore ........................................................................140 Thulasiram, Ruppa K. / University of Manitoba, Canada ........................................................................312, 471 Thulasiraman, Parimala / University of Manitoba, Canada ............................................................................312 Tian, Daxin / Tianjin University, China ..............................................................................................................858 Tilak, Sameer / University of California, San Diego, USA ................................................................................471 Wang, Cho-Li / The University of Hong Kong, Hong Kong ..............................................................................658 Wang, Sheng-De / National Taiwan University, Taiwan ....................................................................................... 123 Wu, Qiang / University of Technology, Australia ...............................................................................................808 Xiang, Yang / Central Queensland University, Australia ...................................................................................858 Xu, Meilian / University of Manitoba, Canada ..................................................................................................312 Yang, Laurence Tianruo / St. Francis Xavier University, Canada ...........................................................442, 841 Yi, Jaeyoung / Yonsei University, Seoul, Korea .................................................................................................276
Ylianttila, Mika / University of Oulu, Finland...................................................................................................682 Yu, Ruo-Jian / National Taiwan University, Taiwan ............................................................................................. 123 Zeng, Qing-An / University of Cincinnati, USA .................................................................................................718 Zhou, Jiehan / University of Oulu, Finland........................................................................................................682 Zhu, Yifeng / University of Maine, USA .............................................................................................................785 Zomaya, Albert Y. / Sydney University, Australia..............................................................................................354
Table of Contents
Foreword .......................................................................................................................................... xxxi Preface ............................................................................................................................................xxxiii Acknowledgment ........................................................................................................................... xxxiv
Volume I Section 1 Grid Architectures and Applications Chapter 1 Pervasive Grid and its Applications ....................................................................................................... 1 Ruay-Shiung Chang, National Dong Hwa University, Taiwan Jih-Sheng Chang, National Dong Hwa University, Taiwan Chapter 2 Pervasive Grids: Challenges and Opportunities ................................................................................... 14 Manish Parashar, Rutgers, The State University of New Jersey, USA Jean-Marc Pierson, Paul Sabatier University, France Chapter 3 Desktop Grids: From Volunteer Distributed Computing to High Throughput Computing Production Platforms ......................................................................................................... 31 Franck Cappello, INRIA & UIUC, France Gilles Fedak, LIP/INRIA, France Derrick Kondo, ENSIMAG - antenne de Montbonnot, France Paul Malécot, Université Paris-Sud, France Ala Rezmerita Université Paris-Sud, France Chapter 4 Porting Applications to Grids................................................................................................................ 62 Wolfgang Gentzsch, EU Project DEISA and Board of Directors of the Open Grid Forum, Germany
Chapter 5 Benchmarking Grid Applications for Performance and Scalability Predictions .................................. 89 Radu Prodan, University of Innsbruck, Austria Farrukh Nadeem, University of Innsbruck, Austria Thomas Fahringer, University of Innsbruck, Austria
Section 2 P2P Computing Chapter 6 Scalable Index and Data Management for Unstructured Peer-to-Peer Networks ...................................123 Shang-Feng Chiang, National Taiwan University, Taiwan Kuo Chiang, National Taiwan University, Taiwan Ruo-Jian Yu, National Taiwan University, Taiwan Sheng-De Wang, National Taiwan University, Taiwan Chapter 7 Hierarchical Structured Peer-to-Peer Networks.................................................................................. 140 Yong Meng Teo, National University of Singapore, Singapore Verdi March, National University of Singapore, Singapore Marian Mihailescu, National University of Singapore, Singapore Chapter 8 Load Balancing in Peer-to-Peer Systems ............................................................................................ 163 Haiying Shen, University of Arkansas, USA Chapter 9 Decentralized Overlay for Federation of Enterprise Clouds............................................................... 191 Rajiv Ranjan, The University of Melbourne, Australia Rajkumar Buyya, The University of Melbourne, Australia
Section 3 Programming Models and Tools Chapter 10 Reliability and Performance Models for Grid Computing ................................................................. 219 Yuan-Shun Dai, University of Electronics Science Technology of China, China & University of Tennessee, Knoxville, USA Jack Dongarra, University of Tennessee, Knoxville, USA; Oak Ridge National Laboratory, USA; & University of Manchester, UK
Chapter 11 Mixed Parallel Programming Models Using Parallel Tasks ............................................................... 246 Jörg Dümmler, Chemnitz University of Technology,Germany Thomas Rauber, University Bayreuth, Germany Gudula Rünger, Chemnitz University of Technology,Germany Chapter 12 Programmability and Scalability on Multi-Core Architectures .......................................................... 276 Jaeyoung Yi, Yonsei University, Seoul, Korea Yong J. Jang, Yonsei University, Seoul, Korea Doohwan Oh, Yonsei University, Seoul, Korea Won W. Ro, Yonsei University, Seoul, Korea Chapter 13 Assembling of Parallel Programs for Large Scale Numerical Modeling............................................ 295 V.E. Malyshkin, Russian Academy of Science, Russia Chapter 14 Cell Processing for Two Scientific Computing Kernels ..................................................................... 312 Meilian Xu, University of Manitoba, Canada Parimala Thulasiraman, University of Manitoba, Canada Ruppa K. Thulasiram, University of Manitoba, Canada
Section 4 Scheduling and Communication Techniques Chapter 15 On Application Behavior Extraction and Prediction to Support and Improve Process Scheduling Decisions ............................................................................................. 338 Evgueni Dodonov, University of São Paulo – ICMC, Brazil Rodrigo Fernandes de Mello, University of São Paulo – ICMC, Brazil Chapter 16 A Structured Tabu Search Approach for Scheduling in Parallel Computing Systems........................ 354 Tore Ferm, Sydney University, Australia Albert Y. Zomaya, Sydney University, Australia Chapter 17 Communication Issues in Scalable Parallel Computing ..................................................................... 378 C.E.R. Alves, Universidade Sao Judas Tadeu, Brazil E. N. Cáceres, Universidade Federal de Mato Grosso do Sul, Brazil F. Dehne, Carleton University, Canada S. W. Song, Universidade de Sao Paulo, Brazil
Chapter 18 Scientific Workflow Scheduling with Time-Related QoS Evaluation ................................................ 396 Wanchun Dou, Nanjing University, P. R. China Jinjun Chen, Swinburne University of Technologies, Australia
Section 5 Service Computing Chapter 19 Grid Transaction Management and Highly Reliable Grid Platform ................................................... 421 Feilong Tang, Shanghai Jiao Tong University, China Minyi Guo, Shanghai Jiao Tong University, China Chapter 20 Error Recovery for SLA-Based Workflows Within the Business Grid ............................................... 442 Dang Minh Quan, International University in Germany, Germany Jorn Altmann, Seoul National University, South Korea Laurence T. Yang, St. Francis Xavier University, Canada Chapter 21 A Fuzzy Real Option Model to Price Grid Compute Resources ........................................................ 471 David Allenotor, University of Manitoba, Canada Ruppa K. Thulasiram, University of Manitoba, Canada Kenneth Chiu, University at Binghamtom, State University of NY, USA Sameer Tilak, University of California, San Diego, USA
Volume II Chapter 22 The State of the Art and Open Problems in Data Replication in Grid Environments ........................ 486 Mohammad Shorfuzzaman, University of Manitoba, Canada Rasit Eskicioglu , University of Manitoba, Canada Peter Graham, University of Manitoba, Canada Chapter 23 Architectural Elements of Resource Sharing Networks ..................................................................... 517 Marcos Dias de Assunção, The University of Melbourne, Australia Rajkumar Buyya, The University of Melbourne, Australia
Section 6 Optimization Techniques Chapter 24 Simultaneous MultiThreading Microarchitecture ............................................................................... 552 Chen Liu, Florida International University, USA Xiaobin Li, Intel® Corporation, USA Shaoshan Liu, University of California, Irvine, USA Jean-Luc Gaudiot, University of California, Irvine, USA Chapter 25 Runtime Adaption Techniques for HPC Applications ........................................................................ 583 Edgar Gabriel, University of Houston, USA Chapter 26 A Scalable Approach to Real-Time System Timing Analysis............................................................. 606 Alan Grigg, Loughborough University, UK Lin Guan, Loughborough University, UK Chapter 27 Scalable Algorithms for Server Allocation in Infostations ................................................................. 645 Alan A. Bertossi, University of Bologna, Italy M. Cristina Pinotti, University of Perugia, Italy Romeo Rizzi, University of Udine, Italy Phalguni Gupta, Indian Institute of Technology Kanpur, India
Section 7 Web Computing Chapter 28 Web Application Server Clustering with Distributed Java Virtual Machine ...................................... 658 King Tin Lam, The University of Hong Kong, Hong Kong Cho-Li Wang, The University of Hong Kong, Hong Kong Chapter 29 Middleware for Community Coordinated Multimedia ....................................................................... 682 Jiehan Zhou, University of Oulu, Finland Zhonghong Ou, University of Oulu, Finland Junzhao Sun, University of Oulu, Finland Mika Rautiainen, University of Oulu, Finland Mika Ylianttila, University of Oulu, Finland
Section 8 Mobile Computing and Ad Hoc Networks Chapter 30 Scalability of Mobile Ad Hoc Networks ............................................................................................. 705 Dan Grigoras, University College Cork, Ireland Daniel C. Doolan, Robert Gordon University, UK Sabin Tabirca, University College Cork, Ireland Chapter 31 Network Selection Strategies and Resource Management Schemes in Integrated Heterogeneous Wireless and Mobile Networks............................................................ 718 Wei Shen, University of Cincinnati, USA Qing-An Zeng, University of Cincinnati, USA
Section 9 Fault Tolerance and QoS Chapter 32 Scalable Internet Architecture Supporting Quality of Service (QoS) ................................................. 739 Priyadarsi Nanda, University of Technology, Sydney (UTS), Australia Xiangjian He, University of Technology, Sydney (UTS), Australia Chapter 33 Scalable Fault Tolerance for Large-Scale Parallel and Distributed Computing ................................. 760 Zizhong Chen, Colorado School of Mines, USA
Section 10 Applications Chapter 34 Efficient Update Control of Bloom Filter Replicas in Large Scale Distributed Systems ................... 785 Yifeng Zhu, University of Maine, USA Hong Jiang, University of Nebraska–Lincoln, USA Chapter 35 Image Partitioning on Spiral Architecture .......................................................................................... 808 Qiang Wu, University of Technology, Australia Xiangjian He, University of Technology, Australia
Chapter 36 Scheduling Large-Scale DNA Sequencing Applications .................................................................... 841 Sudha Gunturu, Oklahoma State University, USA Xiaolin Li, Oklahoma State University, USA Laurence Tianruo Yang, St. Francis Xavier University, Canada Chapter 37 Multi-Core Supported Deep Packet Inspection .................................................................................. 858 Yang Xiang, Central Queensland University, Australia Daxin Tian, Tianjin University, China Chapter 38 State-Carrying Code for Computation Mobility ................................................................................. 874 Hai Jiang, Arkansas State University, USA Yanqing Ji, Gonzaga University, USA
Compilation of References ............................................................................................................... 895
Detailed Table of Contents
Foreword .......................................................................................................................................... xxxi Preface ............................................................................................................................................xxxiii Acknowledgment ........................................................................................................................... xxxiv
Volume I Section 1 Grid Architectures and Applications Chapter 1 Pervasive Grid and its Applications ....................................................................................................... 1 Ruay-Shiung Chang, National Dong Hwa University, Taiwan Jih-Sheng Chang, National Dong Hwa University, Taiwan With the advancements of computer system and communication technologies, Grid computing can be seen as the popular technology bringing about significant revolution for the next generation distributed computing application. As regards general users, a grid middleware is complex to setup and necessitates a steep learning curve. How to access to the grid system transparently from the point of view of users turns into a critical issue then. Therefore, various challenges may arise from the incomprehensive system design as coordinating existing computing resources for the sake of achieving pervasive grid environment. We are going to investigate into the current research works of pervasive grid as well as analyze the most important factors and components for constructing a pervasive grid system here. Finally, in order to facilitate the efficiency in respect of teaching and research within a campus, we would like to introduce our pervasive grid platform. Chapter 2 Pervasive Grids: Challenges and Opportunities ................................................................................... 14 Manish Parashar, Rutgers, The State University of New Jersey, USA Jean-Marc Pierson, Paul Sabatier University, France Pervasive Grid is motivated by the advances in Grid technologies and the proliferation of pervasive systems, and is leading to the emergence of a new generation of applications that use pervasive and ambient
information as an integral part to manage, control, adapt and optimize. However, the inherent scale and complexity of Pervasive Grid systems fundamentally impact how applications are formulated, deployed and managed, and presents significant challenges that permeate all aspects of systems software stack. In this chapter, the authors present some use-cases of Pervasive Grids and highlight their opportunities and challenges. They then present why semantic knowledge and autonomic mechanisms are seen as foundations for conceptual and implementation solutions that can address these challenges. Chapter 3 Desktop Grids: From Volunteer Distributed Computing to High Throughput Computing Production Platforms ......................................................................................................... 31 Franck Cappello, INRIA & UIUC, France Gilles Fedak, LIP/INRIA, France Derrick Kondo, ENSIMAG - antenne de Montbonnot, France Paul Malécot, Université Paris-Sud, France Ala Rezmerita Université Paris-Sud, France Desktop Grids, literally Grids made of Desktop Computers, are very popular in the context of “Volunteer Computing” for large scale “Distributed Computing” projects like SETI@home and Folding@home. They are very appealing, as “Internet Computing” platforms for scientific projects seeking a huge amount of computational resources for massive high throughput computing, like the EGEE project in Europe. Companies are also interested of using cheap computing solutions that does not add extra hardware and cost of ownership. A very recent argument for Desktop Grids is their ecological impact: by scavenging unused CPU cycles without increasing excessively the power consumption, they reduce the waste of electricity. This book chapter presents the background of Desktop Grid, their principles and essential mechanisms, the evolution of their architectures, their applications and the research tools associated with this technology. Chapter 4 Porting Applications to Grids................................................................................................................ 62 Wolfgang Gentzsch, EU Project DEISA and Board of Directors of the Open Grid Forum, Germany Aim of this chapter is to guide developers and users through the most important stages of implementing software applications on Grid infrastructures, and to discuss important challenges and potential solutions. Those challenges come from the underlying grid infrastructure, like security, resource management, and information services; the application data, data management, and the structure, volume, and location of the data; and the application architecture, monolithic or workflow, serial or parallel. As a case study, we present the DEISA Distributed European Infrastructure for Supercomputing Applications and describe its DEISA Extreme Computing Initiative DECI for porting and running scientific grand challenge applications. The chapter concludes with an outlook on Compute Clouds, and suggests ten rules of building a sustainable grid as a prerequisite for long-term sustainability of the grid applications.
Chapter 5 Benchmarking Grid Applications for Performance and Scalability Predictions .................................. 89 Radu Prodan, University of Innsbruck, Austria Farrukh Nadeem, University of Innsbruck, Austria Thomas Fahringer, University of Innsbruck, Austria Application benchmarks can play a key role in analyzing and predicting the performance and scalability of Grid applications, serve as an evaluation of the fitness of a collection of Grid resources for running a specific application or class of applications (Tsouloupas & Dikaiakos, 2007), and help in implementing performance-aware resource allocation policies of real time job schedulers. However, application benchmarks have been largely ignored due to diversified types of applications, multi-constrained executions, dynamic Grid behavior, and heavy computational costs. To remedy these, we present an approach taken by the ASKALON Grid environment that computes application benchmarks considering variations in the problem size of the application and machine size of the Grid site. Our system dynamically controls the number of benchmarking experiments for individual applications and manages the execution of these experiments on different Grid sites. We present experimental results of our method for three real-world applications in the Austrian Grid environment.
Section 2 P2P Computing Chapter 6 Scalable Index and Data Management for Unstructured Peer-to-Peer Networks ...................................123 Shang-Feng Chiang, National Taiwan University, Taiwan Kuo Chiang, National Taiwan University, Taiwan Ruo-Jian Yu, National Taiwan University, Taiwan Sheng-De Wang, National Taiwan University, Taiwan In order to improve the scalability and reduce the traffic of Gnutella-like unstructured peer-to-peer networks, index caching and controlled flooding mechanisms had been an important research topic in recent years. In this chapter we will describe and present the current state of the art about index management schemes, interest groups and data clustering for unstructured peer-to-peer networks. Index caching mechanisms are an approach to reducing the traffic of keyword querying. However, the cached indices may incur redundant replications in the whole network, leading to the less efficient use of storage and the increase of traffic. We propose a multiplayer index management scheme that actively diffuses the indices in the network and groups indices according to their request rate. The peers of the group that have indices with higher request rate will be placed in layers that receive queries earlier. Our simulation shows that the proposed approach can keep a high success query rate as well as reduce the flooding size.
Chapter 7 Hierarchical Structured Peer-to-Peer Networks.................................................................................. 140 Yong Meng Teo, National University of Singapore, Singapore Verdi March, National University of Singapore, Singapore Marian Mihailescu, National University of Singapore, Singapore Structured peer-to-peer networks are scalable overlay network infrastructures that support Internet-scale network applications. A globally consistent peer-to-peer protocol maintains the structural properties of the network with peers dynamically joining, leaving and failing in the network. In this chapter, we discuss hierarchical distributed hash tables (DHT) as an approach to reduce the overhead of maintaining the overlay network. In a two-level hierarchical DHT, the top-level overlay consists of groups of nodes where each group is distinguished by a unique group identifier. In each group, one or more nodes are designated as supernodes and act as gateways to nodes at the second level. Collisions of groups occur when concurrent node joins result in the creation of multiple groups with the same group identifier. This has the adverse effects of increasing the lookup path length due to a larger top-level overlay, and the overhead of overlay network maintenance. We discuss two main approaches to address the group collision problem: collision detection-and-resolution, and collision avoidance. As an example, we describe an implementation of hierarchical DHT by extending Chord as the underlying overlay graph. Chapter 8 Load Balancing in Peer-to-Peer Systems ............................................................................................ 163 Haiying Shen, University of Arkansas, USA Structured peer-to-peer (P2P) overlay networks like Distributed Hash Tables (DHTs) map data items to the network based on a consistent hashing function. Such mapping for data distribution has an inherent load balance problem. Thus, a load balancing mechanism is an indispensable part of a structured P2P overlay network for high performance. The rapid development of P2P systems has posed challenges in load balancing due to their features characterized by large scale, heterogeneity, dynamism, and proximity. An efficient load balancing method should flexible and resilient enough to deal with these characteristics. This chapter will first introduce the P2P systems and the load balancing in P2P systems. It then introduces the current technologies for load balancing in P2P systems, and provides a case study of a dynamism-resilient and proximity-aware load balancing mechanism. Finally, it indicates the future and emerging trends of load balancing, and concludes the chapter. Chapter 9 Decentralized Overlay for Federation of Enterprise Clouds............................................................... 191 Rajiv Ranjan, The University of Melbourne, Australia Rajkumar Buyya, The University of Melbourne, Australia This chapter describes Aneka-Federation, a decentralized and distributed system that combines enterprise Clouds, overlay networking, and structured peer-to-peer techniques to create scalable wide-area networking of compute nodes for high-throughput computing. The Aneka-Federation integrates numerous small scale Aneka Enterprise Cloud services and nodes that are distributed over multiple control and enterprise domains as parts of a single coordinated resource leasing abstraction. The system is designed with the
aim of making distributed enterprise Cloud resource integration and application programming flexible, efficient, and scalable. The system is engineered such that it: enables seamless integration of existing Aneka Enterprise Clouds as part of single wide-area resource leasing federation; self-organizes the system components based on a structured peer-to-peer routing methodology; and presents end-users with a distributed application composition environment that can support variety of programming and execution models. This chapter describes the design and implementation of a novel, extensible and decentralized peer-to-peer technique that helps to discover, connect and provision the services of Aneka Enterprise Clouds among the users who can use different programming models to compose their applications. Evaluations of the system with applications that are programmed using the Task and Thread execution models on top of an overlay of Aneka Enterprise Clouds have been described here.
Section 3 Programming Models and Tools Chapter 10 Reliability and Performance Models for Grid Computing ................................................................. 219 Yuan-Shun Dai, University of Electronics Science Technology of China, China & University of Tennessee, Knoxville, USA Jack Dongarra, University of Tennessee, Knoxville, USA; Oak Ridge National Laboratory, USA; & University of Manchester, UK Grid computing is a newly developed technology for complex systems with large-scale resource sharing, wide-area communication, and multi-institutional collaboration. It is hard to analyze and model the Grid reliability because of its largeness, complexity and stiffness. Therefore, this chapter introduces the Grid computing technology, presents different types of failures in grid system, models the grid reliability with star structure and tree structure, and finally studies optimization problems for grid task partitioning and allocation. The chapter then presents models for star-topology considering data dependence and treestructure considering failure correlation. Evaluation tools and algorithms are developed, evolved from Universal generating function and Graph Theory. Then, the failure correlation and data dependence are considered in the model. Numerical examples are illustrated to show the modeling and analysis. Chapter 11 Mixed Parallel Programming Models Using Parallel Tasks ............................................................... 246 Jörg Dümmler, Chemnitz University of Technology,Germany Thomas Rauber, University Bayreuth, Germany Gudula Rünger, Chemnitz University of Technology,Germany Parallel programming models using parallel tasks have shown to be successful for increasing scalability on medium-size homogeneous parallel systems. Several investigations have shown that these programming models can be extended to hierarchical and heterogeneous systems which will dominate in the future. In this article, we discuss parallel programming models with parallel tasks and describe these programming models in the context of other approaches for mixed task and data parallelism. We discuss compiler-based as well as library-based approaches for task programming and present extensions
to the model which allow a flexible combination of parallel tasks and an optimization of the resulting communication structure. Chapter 12 Programmability and Scalability on Multi-Core Architectures .......................................................... 276 Jaeyoung Yi, Yonsei University, Seoul, Korea Yong J. Jang, Yonsei University, Seoul, Korea Doohwan Oh, Yonsei University, Seoul, Korea Won W. Ro, Yonsei University, Seoul, Korea In this chapter, we will describe today’s technological trends on building a multi-core based microprocessor and its programmability and scalability issues. Ever since multi-core processors have been commercialized, we have seen many different multi-core processors. However, the issues related to how to utilize the physical parallelism of cores for software execution have not been suitably addressed so far. Compared to implementing multiple identical cores on a single chip, separating an original sequential program into multiple running threads has been an even more challenging task. In this chapter, we introduce several different software programs which can be successfully ported on the future multi-core based processors and describe how they could benefit from the multi-core systems. Towards the end, the future trends in the multi-core systems are overviewed. Chapter 13 Assembling of Parallel Programs for Large Scale Numerical Modeling............................................ 295 V.E. Malyshkin, Russian Academy of Science, Russia The main ideas of the Assembly Technology (AT) in its application to parallel implementation of large scale realistic numerical models on a rectangular mesh are considered and demonstrated by the parallelization (fragmentation) of the Particle-In-Cell method (PIC) application to solution of the problem of energy exchange in plasma cloud. The implementation of the numerical models with the assembly technology is based on the construction of a fragmented parallel program. Assembling of a numerical simulation program under AT provides automatically different useful dynamic properties of the target program including dynamic load balance on the basis of the fragments migration from overloaded into underloaded processor elements of a multicomputer. Parallel program assembling approach also can be considered as combination and adaptation for parallel programming of the well known modular programming and domain decomposition techniques and supported by the system software for fragmented programs assembling. Chapter 14 Cell Processing for Two Scientific Computing Kernels ..................................................................... 312 Meilian Xu, University of Manitoba, Canada Parimala Thulasiraman, University of Manitoba, Canada Ruppa K. Thulasiram, University of Manitoba, Canada This chapter uses two scientific computing kernels to illustrate challenges of designing parallel algorithms for one heterogeneous multi-core processor, the Cell Broadband Engine processor (Cell/B.E.). It describes
the limitation of the current parallel systems using single-core processors as building blocks. The limitation deteriorates the performance of applications which have data-intensive and computation-intensive kernels such as Finite Difference Time Domain (FDTD) and Fast Fourier Transform (FFT). FDTD is a regular problem with nearest neighbour comminuncation pattern under synchronization constraint. FFT based on indirect swap network (ISN) modifies the data mapping in traditional Cooley-Tukey butterfly network to improve data locality, hence reducing the communication and synchronization overhead. The authors hope to unleash the Cell/B.E. and design parallel FDTD and parallel FFT based on ISN by taking into account unique features of Cell/B.E. such as its eight SIMD processing units on the single chip and its high-speed on-chip bus.
Section 4 Scheduling and Communication Techniques Chapter 15 On Application Behavior Extraction and Prediction to Support and Improve Process Scheduling Decisions ............................................................................................. 338 Evgueni Dodonov, University of São Paulo – ICMC, Brazil Rodrigo Fernandes de Mello, University of São Paulo – ICMC, Brazil The knowledge of application behavior allows predicting their expected workload and future operations. Such knowledge can be used to support, improve and optimize scheduling decisions by distributing data accesses and minimizing communication overheads. Different techniques can be used to obtain such knowledge, varying from simple source code analysis, sequential access pattern extraction, history-based approaches and on-line behavior extraction methods. The extracted behavior can be later classified into different groups, representing process execution states, and then used to predict future process events. This chapter describes different approaches, strategies and methods for application behavior extraction and classification, and also how this information can be used to predict new events, focusing on distributed process scheduling. Chapter 16 A Structured Tabu Search Approach for Scheduling in Parallel Computing Systems........................ 354 Tore Ferm, Sydney University, Australia Albert Y. Zomaya, Sydney University, Australia Task allocation and scheduling are essential for achieving the high performance expected of parallel computing systems. However, there are serious issues pertaining to the efficient utilization of computational resources in such systems that need to be resolved, such as, achieving a balance between system throughput and execution time. Moreover, many scheduling techniques involve massive task graphs with complex precedence relations, processing costs, and inter-task communication costs. In general, there are two main issues that should be highlighted: problem representation and finding an efficient solution in a timely fashion. In the work proposed here, we have attempted to overcome the first problem by using a structured model which offers a systematic method for the representation of the scheduling problem. The model used can encode almost all of the parameters involved in a scheduling problem in a very
systematic manner. To address the second problem, a Tabu Search algorithm is used to allocate tasks to processors in a reasonable amount of time. The use of Tabu Search has the advantage of obtaining solutions to more general instances of the scheduling problem in reasonable time spans. The efficiency of the proposed framework is demonstrated by using several case studies. A number of evaluation criteria will be used to optimize the schedules. Communication- and computation-intensive task graphs are analyzed, as are a number of different task graph shapes and sizes. Chapter 17 Communication Issues in Scalable Parallel Computing ..................................................................... 378 C.E.R. Alves, Universidade Sao Judas Tadeu, Brazil E. N. Cáceres, Universidade Federal de Mato Grosso do Sul, Brazil F. Dehne, Carleton University, Canada S. W. Song, Universidade de Sao Paulo, Brazil In this book chapter, we discuss some important communication issues to obtain a highly scalable computing system. We consider the CGM (Coarse-Grained Multicomputer) model, a realistic computing model to obtain scalable parallel algorithms. The communication cost is modeled by the number of communication rounds and the objective is to design algorithms that require the minimum number of communication rounds. We discuss some important issues and make considerations of practical importance, based on our previous experience in the design and implementation of parallel algorithms. The first issue is the amount of data transmitted in a communication round. For a practical implementation to be successful we should attempt to minimize this amount, even when it is already within the limit allowed by the CGM model. The second issue concerns the trade-off between the number of communication rounds which the CGM attempts to minimize and the overall communication time taken in the communication rounds. Sometimes a larger number of communication rounds may actually reduce the total amount of data transmitted in the communications rounds. These two issues have guided us to present efficient parallel algorithms for the string similarity problem, used as an illustration.
Chapter 18 Scientific Workflow Scheduling with Time-Related QoS Evaluation ................................................ 396 Wanchun Dou, Nanjing University, P. R. China Jinjun Chen, Swinburne University of Technologies, Australia This chapter introduces a scheduling approach for cross-domain scientific workflow execution with timerelated QoS evaluation. Generally, scientific workflow execution often spans self-managing administrative domains to achieving global collaboration advantage. In practice, it is infeasible for a domain-specific application to disclose its process details for privacy or security reasons. Consequently, it is a challenging endeavor to coordinate scientific workflows and its distributed domain-specific applications from service invocation perspective. Therefore, in this chapter, we aim at proposing a collaborative scheduling approach, with time-related QoS evaluation, for navigating cross-domain collaboration. Under this collaborative scheduling approach, a private workflow fragment could maintain temporal consistency with a global scientific workflow in resource sharing and task enactments. Furthermore, an evaluation is presented to demonstrate the scheduling approach.
Section 5 Service Computing Chapter 19 Grid Transaction Management and Highly Reliable Grid Platform ................................................... 421 Feilong Tang, Shanghai Jiao Tong University, China Minyi Guo, Shanghai Jiao Tong University, China As Grid technology is expanding from scientific computing to business applications, open grid platform increasingly needs the support of transaction services. This chapter proposes a grid transaction service (GridTS) and GridTS based transaction processing model, defines two kinds of grid transactions: atomic grid transaction for short-lived reliable applications and long-lived transaction for business processes. We also present solutions to managing these two kinds of transactions to reach different consistent requirements. Moreover, this chapter investigates a mechanism for automatic generation of compensating transactions in the execution of long-lived transactions through the GridTS. Finally, we discuss the future trends along the reliable grid platform research. Chapter 20 Error Recovery for SLA-Based Workflows Within the Business Grid ............................................... 442 Dang Minh Quan, International University in Germany, Germany Jorn Altmann, Seoul National University, South Korea Laurence T. Yang, St. Francis Xavier University, Canada This chapter describes the error recovery mechanisms in the system handling the Grid-based workflow within the Service Level Agreement (SLA) context. It classifies the errors into two main categories. The first is the large-scale errors when one or several Grid sites are detached from the Grid system at a time. The second is the small-scale errors which may happen inside an RMS. For each type of error, the chapter introduces a recovery mechanism with the SLA context imposing the goal to the mechanisms. The authors believe that it is very useful to have an error recovery framework to avoid or eliminate the negative effects of the errors. Chapter 21 A Fuzzy Real Option Model to Price Grid Compute Resources ........................................................ 471 David Allenotor, University of Manitoba, Canada Ruppa K. Thulasiram, University of Manitoba, Canada Kenneth Chiu, University at Binghamtom, State University of NY, USA Sameer Tilak, University of California, San Diego, USA A computational grid is a geographically disperssed heterogeneous computing facility owned by dissimilar organizations with diverse usage policies. As a result, guaranteeing grid resources availability as well as pricing them raises a number of challenging issues varying from security to management of the grid resources. In this chapter we design and develop a grid resources pricing model using a fuzzy real option approach and show that finance models can be effectively used to price grid resources.
Volume II Chapter 22 The State of the Art and Open Problems in Data Replication in Grid Environments ........................ 486 Mohammad Shorfuzzaman, University of Manitoba, Canada Rasit Eskicioglu , University of Manitoba, Canada Peter Graham, University of Manitoba, Canada Data Grids provide services and infrastructure for distributed data-intensive applications that need to access, transfer and modify massive datasets stored at distributed locations around the world. For example, the next-generation of scientific applications such as many in high-energy physics, molecular modeling, and earth sciences will involve large collections of data created from simulations or experiments. The size of these data collections is expected to be of multi-terabyte or even petabyte scale in many applications. Ensuring efficient, reliable, secure and fast access to such large data is hindered by the high latencies of the Internet. The need to manage and access multiple petabytes of data in Grid environments, as well as to ensure data availability and access optimization are challenges that must be addressed. Chapter 23 Architectural Elements of Resource Sharing Networks ..................................................................... 517 Marcos Dias de Assunção, The University of Melbourne, Australia Rajkumar Buyya, The University of Melbourne, Australia This chapter first presents taxonomies on approaches for resource allocation across resource sharing networks such as Grids. It then examines existing systems and classifies them under their architectures, operational models, support for the life-cycle of virtual organisations, and resource control techniques. Resource sharing networks have been established and used for various scientific applications over the last decade. The early ideas of Grid computing have foreseen a global and scalable network that would provide users with resources on demand. In spite of the extensive literature on resource allocation and scheduling across organisational boundaries, these resource sharing networks mostly work in isolation, thus contrasting with the original idea of Grid computing. Several efforts have been made towards providing architectures, mechanisms, policies and standards that may enable resource allocation across Grids. A survey and classification of these systems are relevant for the understanding of different approaches utilised for connecting resources across organisations and virtualisation techniques. In addition, a classification also sets the ground for future work on inter-operation of Grids.
Section 6 Optimization Techniques Chapter 24 Simultaneous MultiThreading Microarchitecture ............................................................................... 552 Chen Liu, Florida International University, USA Xiaobin Li, Intel® Corporation, USA Shaoshan Liu, University of California, Irvine, USA Jean-Luc Gaudiot, University of California, Irvine, USA Due to the conventional sequential programming model, the Instruction-Level Parallelism (ILP) that modern superscalar processors can explore is inherently limited. Hence, multithreading architectures have been proposed to exploit Thread-Level Parallelism (TLP) in addition to conventional ILP. By issuing and executing instructions from multiple threads at each clock cycle, Simultaneous MultiThreading (SMT) achieves some of the best possible system resource utilization and accordingly higher instruction throughput. In this chapter, we describe the origin of SMT microarchitecture, comparing it with other multithreading microarchitectures. We identify several key aspects for high-performance SMT design: fetch policy, handling long-latency instructions, resource sharing control, synchronization and communication. We also describe some potential benefits of SMT microarchitecture: SMT for fault-tolerance and SMT for secure communications. Given the need to support sequential legacy code and emerge of new parallel programming model, we believe SMT microarchitecture will play a vital role as we enter the multi-thread multi/many-core processor design era. Chapter 25 Runtime Adaption Techniques for HPC Applications ........................................................................ 583 Edgar Gabriel, University of Houston, USA This chapter discusses runtime adaption techniques targeting high-performance computing applications. In order to exploit the capabilities of modern high-end computing systems, applications and system software have to be able to adapt their behavior to hardware and application characteristics. Using the Abstract Data and Communication Library (ADCL) as the driving example, the chapter shows the advantage of using adaptive techniques to exploit characteristics of the network and of the application. This allows to reduce the execution time of applications significantly and to avoid having to maintain different architecture dependent versions of the source code. Chapter 26 A Scalable Approach to Real-Time System Timing Analysis............................................................. 606 Alan Grigg, Loughborough University, UK Lin Guan, Loughborough University, UK This Chapter describes a real-time system performance analysis approach known as reservation-based analysis (RBA). The scalability of RBA is derived from an abstract (target-independent) representation of system software components, their timing and resource requirements and run-time scheduling policies. The RBA timing analysis framework provides an evolvable modeling solution that can be
instigated in early stages of system design, long before the software and hardware components have been developed, and continually refined through successive stages of detailed design, implementation and testing. At each stage of refinement, the abstract model provides a set of best-case and worst-case timing ‘guarantees’ that will be delivered subject to a set of scheduling ‘obligations’ being met by the target system implementation. An abstract scheduling model, known as the rate-based execution model then provides an implementation reference model with which compliance will ensure that the imposed set of timing obligations will be met by the target system. Chapter 27 Scalable Algorithms for Server Allocation in Infostations ................................................................. 645 Alan A. Bertossi, University of Bologna, Italy M. Cristina Pinotti, University of Perugia, Italy Romeo Rizzi, University of Udine, Italy Phalguni Gupta, Indian Institute of Technology Kanpur, India The server allocation problem arises in isolated infostations, where mobile users going through the coverage area require immediate high-bit rate communications such as web surfing, file transferring, voice messaging, email and fax. Given a set of service requests, each characterized by a temporal interval and a category, an integer k, and an integer hc for each category c, the problem consists in assigning a server to each request in such a way that at most k mutually simultaneous requests are assigned to the same server at the same time, out of which at most hc are of category c, and the minimum number of servers is used. Since this problem is computationally intractable, a scalable 2-approximation on-line algorithm is exhibited. Generalizations of the problem are considered, which contain bin-packing, multiprocessor scheduling, and interval graph coloring as special cases, and admit scalable on-line algorithms providing constant approximations.
Section 7 Web Computing Chapter 28 Web Application Server Clustering with Distributed Java Virtual Machine ...................................... 658 King Tin Lam, The University of Hong Kong, Hong Kong Cho-Li Wang, The University of Hong Kong, Hong Kong Web application servers, being today’s enterprise application backbone, have warranted a wealth of J2EE-based clustering technologies. Most of them however need complex configurations and excessive programming effort to retrofit applications for cluster-aware execution. This chapter proposes a clustering approach based on distributed Java virtual machine (DJVM). A DJVM is a collection of extended JVMs that enables parallel execution of a multithreaded Java application over a cluster. A DJVM achieves transparent clustering and resource virtualization, extolling the virtue of single-system-image (SSI). We evaluate this approach through porting Apache Tomcat to our JESSICA2 DJVM and identify scalability issues arising from fine-grain object sharing coupled with intensive synchronizations among distributed threads. By leveraging relaxed cache coherence protocols, we are able to conquer the scalability barri-
ers and harness the power of our DJVM’s global object space design to significantly outstrip existing clustering techniques for cache-centric web applications. Chapter 29 Middleware for Community Coordinated Multimedia ....................................................................... 682 Jiehan Zhou, University of Oulu, Finland Zhonghong Ou, University of Oulu, Finland Junzhao Sun, University of Oulu, Finland Mika Rautiainen, University of Oulu, Finland Mika Ylianttila, University of Oulu, Finland Community Coordinated Multimedia (CCM) envisions a novel paradigm that enables the user to consume multiple media through requesting multimedia-intensive Web services via diverse display devices, converged networks, and heterogeneous platforms within a virtual, open and collaborative community. These trends yield new requirements for CCM middleware. This chapter aims to systematically and extensively describe middleware challenges and opportunities to realize the CCM paradigm by reviewing the activities of middleware with respect to four viewpoints, namely mobility-aware, multimedia-driven, service-oriented, and community-coordinated.
Section 8 Mobile Computing and Ad Hoc Networks Chapter 30 Scalability of Mobile Ad Hoc Networks ............................................................................................. 705 Dan Grigoras, University College Cork, Ireland Daniel C. Doolan, Robert Gordon University, UK Sabin Tabirca, University College Cork, Ireland This chapter addresses scalability aspects of mobile ad hoc networks management and clusters built on top of them. Mobile ad hoc networks are created by mobile devices without the help of any infrastructure for the purpose of communication and service sharing. As a key supporting service, the management of mobile ad hoc networks is identified as an important aspect of their exploitation. Obviously, management must be simple, effective, consume least of resources, reliable and scalable. The first section of this chapter discusses different incarnations of the management service of mobile ad hoc networks considering the above mentioned characteristics. Cluster computing is an interesting computing paradigm that, by aggregation of network hosts, provides more resources than available on each of them. Clustering mobile and heterogeneous devices is not an easy task as it is proven in the second part of the chapter. Both sections include innovative solutions for the management and clustering of mobile ad hoc networks, proposed by the authors.
Chapter 31 Network Selection Strategies and Resource Management Schemes in Integrated Heterogeneous Wireless and Mobile Networks............................................................ 718 Wei Shen, University of Cincinnati, USA Qing-An Zeng, University of Cincinnati, USA Integrated heterogeneous wireless and mobile network (IHWMN) is introduced by combing different types of wireless and mobile networks (WMNs) in order to provide more comprehensive service such as high bandwidth with wide coverage. In an IHWMN, a mobile terminal equipped with multiple network interfaces can connect to any available network, even multiple networks at the same time. The terminal also can change its connection from one network to other networks while still keeping its communication alive. Although IHWMN is very promising and a strong candidate for future WMNs, it brings a lot of issues because different types of networks or systems need to be integrated to provide seamless service to mobile users. In this chapter, we focus on some major issues in IHWMN. Several noel network selection strategies and resource management schemes are also introduced for IHWMN to provide better resource allocation for this new network architecture.
Section 9 Fault Tolerance and QoS Chapter 32 Scalable Internet Architecture Supporting Quality of Service (QoS) ................................................. 739 Priyadarsi Nanda, University of Technology, Sydney (UTS), Australia Xiangjian He, University of Technology, Sydney (UTS), Australia The evolution of Internet and its successful technologies has brought a tremendous growth in business, education, research etc. over the last four decades. With the dramatic advances in multimedia technologies and the increasing popularity of real-time applications, recently Quality of Service (QoS) support in the Internet has been in great demand. Deployment of such applications over the Internet in recent years, and the trend to manage them efficiently with a desired QoS in mind, researchers have been trying for a major shift from its Best Effort (BE) model to a service oriented model. Such efforts have resulted in Integrated Services (Intserv), Differentiated Services (Diffserv), Multi Protocol Label Switching (MPLS), Policy Based Networking (PBN) and many more technologies. But the reality is that such models have been implemented only in certain areas in the Internet not everywhere and many of them also faces scalability problem while dealing with huge number of traffic flows with varied priority levels in the Internet. As a result, an architecture addressing scalability problem and satisfying end-to-end QoS still remains a big issue in the Internet. In this Chapter we propose a policy based architecture which we believe can achieve scalability while offering end to end QoS in the Internet.
Chapter 33 Scalable Fault Tolerance for Large-Scale Parallel and Distributed Computing ................................. 760 Zizhong Chen, Colorado School of Mines, USA Today’s long running scientific applications typically tolerate failures by checkpoint/restart in which all process states of an application are saved into stable storage periodically. However, as the number of processors in a system increases, the amount of data that need to be saved into stable storage also increases linearly. Therefore, the classical checkpoint/restart approach has a potential scalability problem for large parallel systems. In this chapter, we introduce some scalable techniques to tolerate a small number of process failures in large parallel and distributed computing. We present several encoding strategies for diskless checkpointing to improve the scalability of the technique. We introduce the algorithm-based checkpoint-free fault tolerance technique to tolerate fail-stop failures without checkpoint or rollback recovery. Coding approaches and floating-point erasure correcting codes are also introduced to help applications to survive multiple simultaneous process failures. The introduced techniques are scalable in the sense that the overhead to survive k failures in p processes does not increase as the number of processes p increases. Experimental results demonstrate that the introduced techniques are highly scalable.
Section 10 Applications Chapter 34 Efficient Update Control of Bloom Filter Replicas in Large Scale Distributed Systems ................... 785 Yifeng Zhu, University of Maine, USA Hong Jiang, University of Nebraska–Lincoln, USA This chapter discusses the false rates of Bloom filters in a distributed environment. A Bloom filter (BF) is a space-efficient data structure to support probabilistic membership query. In distributed systems, a Bloom filter is often used to summarize local services or objects and this Bloom filter is replicated to remote hosts. This allows remote hosts to perform fast membership query without contacting the original host. However, when the services or objects are changed, the remote Bloom replica may become stale. This chapter analyzes the impact of staleness on the false positive and false negative for membership queries on a Bloom filter replica. An efficient update control mechanism is then proposed based on the analytical results to minimize the updating overhead. This chapter validates the analytical models and the update control mechanism through simulation experiments. Chapter 35 Image Partitioning on Spiral Architecture .......................................................................................... 808 Qiang Wu, University of Technology, Australia Xiangjian He, University of Technology, Australia Spiral Architecture is a relatively new and powerful approach to image processing. It contains very useful geometric and algebraic properties. Based on the abundant research achievements in the past decades, it is shown that Spiral Architecture will play an increasingly important role in image processing and
computer vision. This chapter presents a significant application of Spiral Architecture for distributed image processing. It demonstrates the impressive characteristics of spiral architecture for high performance image processing. The proposed method tackles several challenging practical problems during the implementation. The proposed method reduces the data communication between the processing nodes and is configurable. Moreover, the proposed partitioning scheme has a consistent approach: after image partitioning each sub-image should be a representative of the original one without changing the basic object, which is important to the related image processing operations. Chapter 36 Scheduling Large-Scale DNA Sequencing Applications .................................................................... 841 Sudha Gunturu, Oklahoma State University, USA Xiaolin Li, Oklahoma State University, USA Laurence Tianruo Yang, St. Francis Xavier University, Canada This chapter studies a load scheduling strategy with near-optimal processing time that is designed to explore the computational characteristics of DNA sequence alignment algorithms, specifically, the Needleman-Wunsch Algorithm. Following the divisible load scheduling theory, an efficient load scheduling strategy is designed in large-scale networks so that the overall processing time of the sequencing tasks is minimized. In this study, the load distribution depends on the length of the sequence and number of processors in the network and, the total processing time is also affected by communication link speed. Several cases have been considered in the study by varying the sequences, communication and computation speeds, and number of processors. Through simulation and numerical analysis, this study demonstrates that for a constant sequence length as the numbers of processors increase in the network the processing time for the job decreases and minimum overall processing time is achieved. Chapter 37 Multi-Core Supported Deep Packet Inspection .................................................................................. 858 Yang Xiang, Central Queensland University, Australia Daxin Tian, Tianjin University, China Network security applications such as intrusion detection systems (IDSs), firewalls, anti-virus/spyware systems, anti-spam systems, and security visualisation applications are all computing-intensive applications. These applications all heavily rely on deep packet inspection, which is to examine the content of each network packet’s payload. Today these security applications cannot cope with the speed of broadband Internet that has already been deployed, that is, the processor power is much slower than the bandwidth power. Recently the development of multi-core processors brings more processing power. Multi-core processors represent a major evolution in computing hardware technology. While two years ago most network processors and personal computer microprocessors had single core configuration, the majority of the current microprocessors contain dual or quad cores and the number of cores on die is expected to grow exponentially over time. The purpose of this chapter is to discuss the research on using multi-core technologies to parallelize deep packet inspection algorithms, and how such an approach will improve the performance of deep packet inspection applications. This will eventually provide a security system the capability of real-time packet inspection thus significantly improve the overall status of security on current Internet infrastructure.
Chapter 38 State-Carrying Code for Computation Mobility ................................................................................. 874 Hai Jiang, Arkansas State University, USA Yanqing Ji, Gonzaga University, USA Computation mobility enables running programs to move around among machines and is the essence of performance gain, fault tolerance, and system throughput increase. State-carrying code (SCC) is a software mechanism to achieve such computation mobility by saving and retrieving computation states during normal program execution in heterogeneous multi-core/many-core clusters. This chapter analyzes different kinds of state saving/retrieving mechanisms for their pros and cons. To achieve a portable, flexible and scalable solution, SCC adopts the application-level thread migration approach. Major deployment features are explained and one example system, MigThread, is used to illustrate implementation details. Future trends are given to point out how SCC can evolve into a complete lightweight virtual machine. New high productivity languages might step in to raise SCC to language level. With SCC, thorough resource utilization is expected.
Compilation of References ............................................................................................................... 895
xxxi
Foreword
I am delighted to write the Foreword to this book, as it is a very useful resource in a time where change is dramatic and guidance on how to proceed in the development and use of scalable computing technology is in demand. The book is timely, as it comes at the meeting point of two major challenges and opportunities. Information technology, having grown at an increasingly rapid pace since the construction of the first electronic computer, has now reached a point where it represents an essential, new and transformational enabler of progress in science, engineering, and the commercial world. The performance of today's computer hardware and the sophistication of their software systems yield a qualitatively new tool for scientific discovery, industrial engineering, and business solutions. The solutions complement and promise to go beyond those achievable with the classical two pillars of science - theory and real-world experiments. The opportunity of the third pillar is substantial; however, building it is still a significant challenge. The second challenge and opportunity lays is the current transformation that the computer industry is undergoing. The emergence of multicore processors has been called "the greatest disruption information technology has seen." As several decades of riding Moore's law to easily accelerate clock speeds have come to and end, parallel hardware and software solutions must be developed. While the challenge of creating such solutions is formidable, it also represents an opportunity that is sure to create food for thought and work for new generations of scientists, engineers, students, and practitioners. Scalable computing technologies are at the core of both challenges; they help create the hardware and software architectures underlying the third pillar of science and they help create the parallel computing solutions that will make or break the multicore revolution. The book addresses many issues related to these challenges and opportunities. Among them is the question of the computer model of the future. Will we continue to obtain computer services from local workstations and personal computers? Will the compute power be concentrated in servers? Will these systems be connected in the form of Grids? The book also discusses the Cloud model, where the end user obtains all information services via networks from providers "out there" - possibly via small hand-held devices. Embedded and real-time computer systems are another factor in this equation, as information technology continues to penetrate all appliances, equipment, and wearables in our daily lives. While computer systems evolve, the question of the relevant new applications continues to boggle our minds. Classical performance-thirsty programs are those in the area of science and engineering. Future scalable applications are likely to include business and personal software, such as web and mobile applications, tools running on ad-hoc networks, and a myriad of entertainment software. Among the grandest challenges is the question of programming tools and environments for future, scalable software. In the past, parallel programming has been a niche for a small number of scientists and geeks. With multicores and large-scale parallel systems, this technology now must quickly be learned by masses of software engineers. Many new models are being proposed. They include those where multiple
xxxii
cores and computers communicate by exchanging messages as well as those that share a global address space. The book also discusses mixed models, which will likely have an important role in bridging and integrating heterogeneous computer architectures. The book touches on both classical and newly emerging issues to reach for the enormous opportunities ahead. Among the classical issues are those of performance analysis and modeling, benchmarking, development of scalable algorithms, communication, and resource management. While many solutions to these issues have been proposed in the past, evolving them to true scalability is likely to lead to many more doctoral dissertations at universities and technologies in industries. Among the chief pressing new issues is the creation of scalable hardware and software solutions. Tomorrow's high-performance computers may contain millions of processors; even their building blocks may contain tens of cores within foreseeable time. Today's hardware and software solutions are simply inadequate to deal with this sheer scale. Managing power and energy is another issue that has emerged as a major concern. On one hand, power dissipation of computer chips is the major reason that clock speeds can no longer increase; on the other hand, the overall consumption of information technology's power has risen to a political issue - we will soon use more energy for information processing than for moving matter! Furthermore, as computer systems scale to a phenomenal number of parts, their dependability is of increasing concern; failures and their tolerance may need to be considered as part of standard operating procedures. Among the promising principles underlying many of these technologies is that of dynamic adaptation. Future hardware and software systems may no longer by static. They many change, adapting to new data, environments, faults, resource availability, power, and user demands. They may dynamically incorporate newly available technology, possibly creating computer solutions that evolve continually. The large number of challenges, opportunities, and solutions presented herein will benefit a broad readership from students, to scientists, to practitioners. I am pleased to be able to recommend this book to all those who are looking to learn, use, and contribute to future scalable computing technologies.
Rudolf Eigenmann Professor of Electrical and Computer Engineering and Technical Director for HPC, Computing Research Institute Purdue University November 2008
Rudolf Eigenmann is a professor at the School of Electrical and Computer Engineering and Technical Director for HPC of the Computing Research Institute at Purdue University. His research interests include optimizing compilers, programming methodologies and tools, performance evaluation for high-performance computers and applications, and Internet sharing technology. Dr. Eigenmann received a Ph.D. in Electrical Engineering/Computer Science in 1988 from ETH Zurich, Switzerland.
xxxiii
Preface
There is a constantly increasing demand for computational power for solving complex computational problems in science, engineering and business. The past decade has witnessed a proliferation of more and more high-performance scalable computing systems. The impressive progress is mainly due to the availability of enabling technologies in hardware, software or networks. High-end innovations on such enabling technologies have been fundamental and present cost-effective tools to explore the currently available high performance systems to make further progress. To that end, this Handbook of Research on Scalable Computing Technologies presents, discusses, share ideas, results and experiences on the recent important advances and future challenges on such enabling technologies. This handbook is directed to those interested in: developing programming tools and environments for academic or research computing, extracting the inherent parallelism, and achieving higher performance. This handbook will also be useful for upper-level undergraduate and graduate students studying this subject. Main topics covered in this book are on scalable computing and cover a wide array of topics: • • • • • • • • • • • • • • •
Architectures and systems Software and middleware Data and resource management paradigms Programming models, tools, problem solving environments Trust and security Service-oriented computing Data-intensive computing Cluster and Grid computing Community and collaborative computing networks Scheduling and load balancing Economic and utility computing models Peer-to-Peer systems Multi-core/Many-core based computing Parallel and distributed techniques Scientific, engineering and business computing
This book is a valuable source targeted to those interested in the development of field of grid engineering for academic or enterprise computing, aimed for computer scientists, researchers and technical managers working all areas of science, engineering and economy from academia, research centers and industries.
xxxiv
Acknowledgment
Of course, the represented areas/topics in this handbook, are not an exhaustive representation of the world of current scalable computing. Nonetheless, they represent the rich and many-faceted knowledge, that we have the pleasure of sharing with the readers. The editors would like to acknowledge all of the authors for their insights and excellent contributions to this handbook and the help of all involved in the collaboration and review process of the handbook, without whose support the project could not have been satisfactorily completed. Most of the authors of chapters included in this handbook also served as referees for chapters written by other authors. Thanks go to all those who provided constructive and comprehensive reviews. Special thanks also go to the publishing team at IGI Global, whose contributions throughout the whole process from inception of the initial idea to final publication have been invaluable. In particular to, Rebecca Beistline, who continuously prodded via e-mail for keeping the project on schedule and to Joel A. Gamon who has been helping us to complete the book project’s production professionally.
Kuan-Ching Li Ching-Hsien Hsu Laurence Tianruo Yang Jack Dongarra Hans Zima
Section 1
Grid Architectures and Applications
1
Chapter 1
Pervasive Grid and its Applications Ruay-Shiung Chang National Dong Hwa University, Taiwan Jih-Sheng Chang National Dong Hwa University, Taiwan
ABSTRACT With the advancements of computer system and communication technologies, Grid computing can be seen as the popular technology bringing about significant revolution for the next generation distributed computing application. As regards general users, a grid middleware is complex to setup and necessitates a steep learning curve. How to access to the grid system transparently from the point of view of users turns into a critical issue then. Therefore, various challenges may arise from the incomprehensive system design as coordinating existing computing resources for the sake of achieving pervasive grid environment. The authors are going to investigate into the current research works of pervasive grid as well as analyze the most important factors and components for constructing a pervasive grid system here. Finally, in order to facilitate the efficiency in respect of teaching and research within a campus, they would like to introduce their pervasive grid platform.
INTRODUCTION The current scientific problems are becoming more and more complex for computers. As the aid of the advances in the computing power of hardware and the diversification of the Internet services, distributed computing applications are becoming more and more important and wide-spread. However, the past technologies such as cluster and parallel computing are insufficient to process the data-intensive or computing-intensive applications with the large amount of data file transmissions. In addition, from the perspective of the most users, a secure and powerful computing environment is beneficial for a tremendous amount of computing jobs and data-intensive applications. Fortunately, a new technology DOI: 10.4018/978-1-60566-661-7.ch001
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Pervasive Grid and its Applications
called grid computing (Reed, 2003; Foster, 2002; Foster, 2001) has been developed to contribute to the powerful computing ability to support such distributed computing applications recently. Grid is a burgeoning technology with the capability of integrating a variety of computing resources as well as scheduling jobs from various sites, in order to supply a number of users with breakthrough computing power at low cost. The most current grid system in operation is on the basis of middleware-based approach. A few grid middleware projects have been developed such as Globus, Legion, UNICORE, and SRB so far. However, as regards general users, a grid middleware is complex to setup and necessitates a steep learning curve. Take Globus as an example, which is now in widespread use for the deployment of grid middleware, only a command mode environment is provided for users. To cooperate with Globus very well must have strong knowledge in grid functions and system architecture. As far as a general user is concerned, it seems rather complex as manipulating grid middleware. Overhead of managing and maintaining a Grid middleware will limit the popularization for users. In addition, it is hard to integrate various computing resources such as mobile devices, handsets, laptops into ubiquitous computing platform due to the deficient system functionalities to underlying heterogeneous resources. How to access to the grid system transparently from the point of view of users turns into a critical issue then. On the other hand, as far as a programmer is concerned, a lack of programming modules may increase the complexity of system development for pervasive grid. Limited support for applications level components also restricts programmers to develop pervasive services. Therefore, various challenges may arise from the incomprehensive system design as coordinating existing computing resources for the sake of achieving pervasive grid environment. We are going to investigate into the current research works of pervasive grid as well as analyze the most important factors and components for constructing a pervasive grid system here. In addition, in order to facilitate the efficiency in respect of teaching and research within a campus, we would like to introduce our pervasive grid platform to make resources available as conveniently as possible. The pervasive grid platform integrates all of the wired and mobile devices into a uniform resource on the grounds of the existing grid infrastructure. Resources can be accessed easily anytime and anywhere through the pervasive grid platform.
CURRENT AND FUTURE RESEARCH TRENDS (Mario, 2003) brought up an architecture of pervasive grid with utilization of diverse grid technologies as indicated in figure 1(a). For example, knowledge grid is able to extract interesting information from a huge amount of data source by means of the data mining technology. Semantic grid is an emerging technology, aiming for the translation of semantic job to corresponding grid job or command. The grid fabric provides various grid services, including data grid and information grid. Data grid intends to process data-intensive jobs by way of the powerful distributed storage system and data management technology in order to bring about superior performance with minimal job exection time. Information grid provides job broker with complete system information for job dispatch. The interconnection between diverse computing resources is achieved via P2P technology coupled with efficient management strategies, tending towards a more fullness architecture. There had been several works (Arshad, 2006; Pradeep Padala, 2003; Vazhkudai, 2002) attempting to develop a high performance framework for grid-enabled operating system. A modular architecture
2
Pervasive Grid and its Applications
Figure 1.
called GridOS (Pradeep Padala, 2003) was proposed in order to provide a layered infrastructure. Four design principles are considered including modularity, policy neutrality, universality of infrastructure, and minimal core operating system changes. Figure 1(b) points out the system framework of GridOS from the point of view of modular design. As regards kernel level, GridOS focuses on a high-performance I/O processing engine. In terms of dataintensive applications, since a large amount of data are distributed and transported across the Internet, how to process these requests in an efficient way is worth a great deal of thought. Two aspects need to be taken into consideration including inner disk I/O processing and TCP transmission throughput. The improvement of inner I/O processing can be realized by integrating user-level FTP service to kernel level one. The overhead of copying data in system-space to user-space can be avoided. As for the improvement of TCP transmission throughput, the optimal buffer size is calculated to maximize the throughput. In addition, there are three modules based on the above I/O processing engine to support multi-thread communication with different quality of service requirement, resource allocation management, and process communication management respectively: • •
Communication module Resource management module
3
Pervasive Grid and its Applications
•
Process management module
(Arshad, 2006) suggested several design points for developing a P2P-based grid operating system. Since centralized system may not be appropriate in support of Plug and Play. That is, if there are many external computing resources attempting to join a pervasive grid environment, the centralized system is hard to manage the join and leave process dynamically in an efficient way. Hence, enabling grid operating system to discovery distributed resources and sharing resources in a P2P fashion transparently may be a proper alternative. Figure 1(c) shows the overall architecture of P2P-based Grid Operating System. The existing gird middleware support only a few types of applications without interactive ones. The layer of grid-enabled process management is going to support grid-enabled interactive applications rather than batch ones. Further, process management layer also dominates process migration which is the transit of a process between two grid nodes. In regard to the underlying connection, each node connects with others by P2P communication in a self-organization way. All near peers are organized into a sub-Grid while a sub-Grid will be a member of a RootGrid. In addition, in order to provide all inter-processes with a grid wide shared memory space for accessing required data, a virtual file system is used to emulate such global data access system. A proxy-based clustered architecture was proposed in (Thomas, 2002) for supporting mobile devices to be integrated into a grid computing environment, as shown in Figure 1(d). A dedicated node called interlocutor running a grid middleware such as Globus is responsible for the job management and resource aggregation on behalf of mobile devices. All requests from users will be handled and decomposed by the interlocutor for further job dispatch or resource requests. This is a scalable way to help mobile devices join a grid computing environment since most part of them is insufficient to install and run a grid middleware. In (Junseok, 2004), a proxy-based wireless grid architecture was proposed. A proxy component is deployed as a interface between computing resources and mobile devices for service managements and QoS requirements. Having built the proxy, a mobile user can connect a grid environment with ease, without taking care of the differences between various mobile devices, for attaining to heterogeneous interworking and pervasive computing. Degistry and discovery mechanism are deployed via Web Service while all non-grid wireless devices are capable of access to grid system as illustrated in Figure 2(a). A conception of pervasive wireless grid was put forward in (Srinivasan, 2005). The whole computing environment consists of a backbone grid and access grids as depicted in Figure 2(b). Mobile devices are considered a terminal to connect the backbone grid. Most of computing jobs are dispatched to the backbone grid. In addition, the impact of service handoff for mobile users is discussed in this paper. In conclusion, under the consideration of the above discussion, to determine the implementation of pervasive grid system with OS level or middleware level depends on the requirements. As indicated in Figure 2(c), the middleware level is suitable for developing a pervasive computing system for mobile devices due to the scalability. Since mobile devices cannot afford the overhead of running a middleware system, a proxy-based approach may be a proper solution. A dedicated proxy server handles the interconnections between mobile devices and grids, and then the join of a grid environment will become easier as for mobile devices. As regards fixed devices with powerful computing ability and storage resources, the implementation based on OS level will be an efficient way to bring all available resources into full play.
4
Pervasive Grid and its Applications
Figure 2.
APPLICATION OF PERVASIVE GRID In this session, we would like to introduce the application based on the pervasive grid conception. In our implementation, we have made use of the Globus Toolkit as our system infrastructure. It provides several fundamental grid technologies along with an open source implementation of a series of grid services and libraries. A few critical components within Globus Toolkit are listed below: • •
•
Security: GSI (Grid Security Infrastructure) provides the authentication and authorization mechanisms for system protection according to X.509 proxy certificates. Data management: It is utilized to manipulate data including GridFTP and RLS (Replica Location Service). RLS maintains location information of replicas from logical file names (LFN) to physical file names (PFN). Execution management: GRAM (The Grid Resource Allocation and Management) provides a series of uniform interfaces to simplify the access of remote grid resources for job execution. A job is defined by RSL (Resource Specification Language) in terms of binary execution file, arguments, standard output, and so forth.
5
Pervasive Grid and its Applications
•
Information services: MDS (Monitoring and Discovery System) enables the monitoring and discovery services for grid resources.
We have developed a portal program on client side by means of the CoG Toolkit. The Java CoG Toolkit provides a series of programming interfaces as well as reusable objects in grid services, such as GSI, GRAM, GridFTP, MDS and so on. It presents programmers with a mapping between the Globus Toolkit and Java APIs, so as to ease the programming complexity. Figure 2(d) reveals the overall architecture of pervasive grid with the hierarchical components. The underlying grid middleware is deployed by the Globus Toolkit. Pervasive grid platform is implemented on the basis of the Globus Toolkit. A service-oriented provider, consisting of data, computation and information service, offers users a comprehensive computing environment. Data transmission and replication are the main operations in data service. We utilize GridFTP as the underlying transmission protocol. Computation service provides the computing resources for job executions. Information service gives up-to-date resource information such as CPU frequency, available memory space and average system loading. Such information could be utilized by region job dispatcher during job submission in order to decide a proper grid site for execution. E-campus applications are built above the platform and services. Pervasive grid system makes use of the advantages of pervasive grid to provide students and teachers with a digitalized education system. From the perspective of the most users, a friendly interface without complicated manipulations is necessary. In order to simplify the interconnection and operations, we have developed a user portal by means of Java CoG Toolkit. Due to the nature of cross-platform execution of Java, our portal solution can run on various operating systems. A user could connect and access the e-campus services in an unsophisticated way via our client portal.
System Overview This research is based on the grid technology in support of pervasive computing for digitalized platform in a campus. We attempt to develop a pervasive grid environment based on the grid computing technology to coordinate all of wireless and wired computing devices within a grid computing environment. From the standpoint of users, all the resources are considered a uniform type regardless of the type of resources. A user can access a variety of resources conveniently through the Web Services deployed in our system. We have adapted the layered-design approach to implement the pervasive grid system. The design framework of pervasive grid system appears in Figure 3(a). The layered-design makes pervasive grid system more flexible if new services are added to the system as needed. Based on the Web Services architecture, we develop a service-oriented provider, which offers users a comprehensive grid computing service, including data, computation and information service. It provides flexibility for future services that support the pervasive grid system. There are five components within pervasive grid system as shown in Figure 3(b): • • • •
6
Core computing infrastructure Edge grid node Web services Pervasive grid platform
Pervasive Grid and its Applications
Figure 3.
•
Applications
The core computing infrastructure is the main computing and storage resource. It provides a computing platform with a capability of storage elements, scheduling system, workflow management. In opposition to the core computing infrastructure, the edge grid node is a terminal, such as notebooks, PDAs, and personal computers, for connection with the core grid infrastructure. An edge grid node could access the grid services as well as publish services to the public. Web Services is a popular technology based on XML and HTTP for the construction of distributed computing applications. It works at an open-architecture with the capability of bridging any programming language, computing hardware or operating system. Accordingly, we adopt Web Services as our software interface, in order to build a uniform entry between an edge grid node and our grid services. As for the pervasive grid platform, it is
7
Pervasive Grid and its Applications
a middleware to provide the basic grid services for users, such as location management, service handoff, and personal information management. In the applications layer, we develop some useful applications based on the pervasive grid platform, including e-Classroom and e-Ecology.
Pervasive Grid Platform In the mater of the core computing infrastructure, it contains the computing power and storage capability, to provide mobile or wired users with grid services. An edge grid node is just a terminal between a user and the core computing infrastructure. It is necessary to provide users with an efficient interface in a seamless and transparent way by the core computing infrastructure. Consequently, it is essential to develop a high-performance platform to process the user’s requirements. There are several works to be addressed as given below in terms of the pervasive grid platform: •
•
•
•
To process the join and leave of edge computing nodes: Our system follows GSI (Grid Security Infrastructure) to design a user authentication/authorization mechanism for adapting to our environment. Managing the interconnection between the core computing infrastructure and edge grid nodes: There are several differences and limitations among various edge grid devices. The pervasive grid platform is capable of managing these differences as well as fit in with user’s QoS (Quality of Service). The interconnection between the pervasive grid platform and core computing infrastructure: As presented in Figure 6, we implement the interface to handle the interconnection between the pervasive grid platform and core computing infrastructure through the Globus APIs. The corresponding algorithm is developed to cope with user’s jobs via Globus as well. Job dispatch, management, and QoS: We are concerned with the development of the flexible, high-performance, and reliable dispatcher and scheduler within the pervasive grid platform, in order to suffice for the requirements of users. Users with different priority could obtain the corresponding service level.
Grid Service Provider On the basis of the pervasive grid platform, we would like to implement a service-oriented provider in a module-design way based on the Web Services technology. It is easy to add or remove a service without taking great pains to maintain system services. For example, Data Grid (Ann Chervenak, 2000; Hoschek, 2000) service is intended to provide a large amount of storage resources and distributed access technology for data-intensive applications. There are three grid service modules within our system, including Data-Grid service, Computational service, and Information service. The computational service is to supply users with computing services for job execution. The information service has the capability of gathering the information about hardware resources. With the exception of the core grid infrastructure, an edge node could also publish and provide some specified services. For instance, a PDA (Personal Digital Assistant) may publish the GPS service to the public. Other edge grid nodes could access the GPS service provided by the PDA. Through the share of services, our system has not merely a better service-oriented architecture, but a complete and diverse service provider. Therefore, as shown in Figure 3(c), it is reasonable to deploy and build a service repository
8
Pervasive Grid and its Applications
Figure 4.
system for maintaining all registered services dynamically such as query, joint, remove for services.
Applications In the light of the development of the pervasive grid platform and service-oriented provider system, we make a study of academic applications within a campus environment called e-Campus system, for teachers and students with the comprehensive services, regarding researches and teaching. There are two applications for e-Campus system, including e-Ecology and e-Classroom. The National Dong Hwa University (NDHU) has widespread natural ecosystem. It is precious treasure for teaching and education. In addition, with regard to visitors, they may feel like understanding and observing the natural environment within NDHU. For this reason above, we are attempted to develop the e-Ecology application, as shown in Figure 3(d), by keeping records of the daily activities of the natural ecology system as video files over a long period of time in NDHU. It is observable that the data size of video files must be very tremendous.
9
Pervasive Grid and its Applications
As presented in Figure 4(a), in order to cope with such large amount data, we have implemented a storage broker based on the Data-Grid technology in support of the e-Ecology system. The overall components of the storage broker are presented in Figure 4 (b). The file mover uses GridFTP as its transmission protocol to copy files between two grid nodes. The upload processing engine gets the space information of each storage node from MDS. We adapt the roulette wheel algorithm (Goldberg, 1989) to the storage broker for choosing a node to upload a file. According to the roulette wheel algorithm, the larger capability of storage resources has the larger probability to be chose, with a view to achieve the system balance for storage resources. Download processing engine is an agent distributed in each node. When the broker gets a download request, it retrieves information from RLS database and redirects this request to the node that contains the file. The download agent receives the request and start transferring file. The Storage Broker would distribute the download jobs to each storage node, in order to shorten the download time. Therefore, users could browse the digital files smoothly without significant delay. The search engine helps us to look for some specific files by some keywords or properties. With the efficient storage broker system, the visitors can join the pervasive grid to access our ecological data via the e-Ecology system, as long as they are authorized. The students or teachers also can investigate into the ecology within NDHU for their researches. In respect of e-Classroom, the video data for a course can be digitalized as well as stored in our system via Data-Grid technology. The students can review the course by browsing the video data via e-Classroom. With the review of courses in multimedia, the teaching efficiency could be improved. In addition, as shown in Figure 4 (c), the teaching data could be shared among various universities for distance learning, so as to achieve the objective of the share of education resources.
Implementation We have implemented an integrated portal of pervasive grid system with a kind user interface called NDHU Grid Client, as shown in Figure 4 (d). NDHU Grid Client is very friendly towards students and teachers even if they have little knowledge of computer. Several functions are integrated in this portal, including user’s certification tool, GridFTP transmission tool, and grid job tool and e-Campus applications. One application is created by an internal frame as an independent thread. Each job will not influence other jobs by means of multi-threading programming model. In the matter of e-Campus applications, take e-Ecology as an example, if we feel like browsing an ecological video file via e-Ecology, we should connect the storage broker at first, as shown in Figure 5(a). Then we input the LFN (Logical File Name) of the video file. The storage broker will search an optimal site containing this file to download via GridFTP. GridFTP supports parallel data transfer using multiple TCP streams to improve the bandwidth over a single one. We make use of parallel data transfer to shorten the waiting time for users. After the transmission, the ecological file is presented through e-Ecology interface, as shown in Figure 5(b).
Performance Evaluation and Analyses GridFTP supports parallel data transfer using multiple TCP streams for better performance. We adapt the parallel data transfer to our system, in order to shorten the download time. Increasing the parallelism of transmissions seems to achieve better performance; it may lead to more computing overhead on account of too many working threads in your system. We have experimented on a variety of the number
10
Pervasive Grid and its Applications
Figure 5.
of TCP data streams from one stream to six, for downloading a video file with 700 Mega Bytes, with a view to determine the appropriate parallelism value. The result is shown in Figure 5(c). It is found from the result that data stream of three is superior to the others. Therefore, we adopt the parallelism as three data streams in our implementation. We have also made experiments on the comparison between the conventional transmission with single stream and the parallel transmission. As shown in Figure 5(d), the result indicates that our transmission model can outperform the conventional one. Users can obtain excellent browsing quality for large size video data via e-Campus system.
CONCLUSION In this chapter, we have investigated into the current research works of pervasive grid as well as analyzed the most important factors and components for constructing a pervasive grid system. Two approaches of implementation of pervasive grid system have been exploited mainly as yet including OS level and middleware level. To determine the implementation of pervasive grid system with OS level or middleware level depends on the system requirements and environment. Finally, we have introduced applications of pervasive grid system.
11
Pervasive Grid and its Applications
RFFERENCES Ali, A., McClatchey, R., Anjum, A., Habib, I., Soomro, K., Asif, M., et al. (2006). From grid middleware to a grid operating system. In Proceedings of the Fifth International Conference on Grid and Cooperative Computing, (pp. 9-16). China: IEEE Computer Society. Cannataro, M., & Talia, D. (2003). Towards the next-generation grid: A pervasive environment for knowledge-based computing. In Proceedings of the International Conference on Information Technology: Computers and Communications (pp.437-441), Italy. Chervenak, A., Foster, L., Kesselman, C., Salisbury, C., & Tueckem, S. (2000). The data grid: Towards an architecture for the distributed management and analysis of large scientific data sets. Journal of Network and Computer Applications, 23(3), 187–200. doi:10.1006/jnca.2000.0110 CoG Toolkit (n.d.). Retrieved from http://www.cogkit.org/ Foster, I. (2002). The grid: A new infrastructure for 21st century science. Physics Today, 55, 42–47. doi:10.1063/1.1461327 Foster, I., Kesselman, C., & Tuecke, S. (2001). The anatomy of the the grid: Enabling scalable virtual organization. The International Journal of Supercomputer Applications, 15(3), 200–222. Globus: Grid security infrastructure (GSI) (n.d.). Retrieved from http://www.globus.org/security/ Globus: The grid resource allocation and management (GRAM) (n.d.). Retrieved from http://www. globus.org/toolkit/docs/3.2/gram/ Goldberg, & D. E. (1989). Genetic algorithm: In search, optimization and machine learning. New York: Addison-Wesley. Grid Computing, I. B. M. (n.d.). Retrieved from http://www-1.ibm.com/grid/ GridFTP (n.d.). Retrieved from http://www.globus.org/toolkit/docs/4.0/data/gridftp/ GSI (Globus Security Infrastructure). Retrieved from http://www.globus.org/Security/ Hoschek, W., Jaen-Martinez, J., Samar, A., Stockinger, H., & Stockinger, K. (2000). Data management in an international data grid project. grid computing - GRID 2000 (pp.333-361). UK. Hwang, J., & Arvamudham, P. (2004). Middleware services for P2P computing in wireless grid networks. IEEE Internet Computing, 8(4)40–46. doi:10.1109/MIC.2004.19 Information Services. (n.d.). Retrieved from http://www.globus.org/toolkit/mds/ Legion (n.d.). from http://www.legion.virginia.edu/ Padala, P., & Wilson, J. N. (2003). GridOS: Operating system services for grid architectures. In High Performance Computing (pp. 353-362). Berlin: Springer. Phan, T., Huang, L., & Dulan, C. (2002). Challenge: Integrating mobile wireless devices into the computational grid. In Proceedings of the 8th annual international conference on Mobile computing and networking (pp. 271-278), USA.
12
Pervasive Grid and its Applications
Reed, D. A. (2003). Grids: The teragrid, and beyond. IEEE Computer, 36(1), 62–68. Replica Location Service (RLS) (n.d.). Retrieved from http://www.globus.org/toolkit/docs/4.0/data/rls/ Siagri, R. (2007). Pervasive computers and the GRID: The birth of a computational exoskeleton for augmented reality. In 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on The foundations of software engineering (pp.1-4), Croatia. SRB (Storage Resource Broker) (n.d.). Retrieved from http://www.sdsc.edu/srb/index.php/Main_Page Srinivasan, S. H. (2005). Pervasive wireless grid architecture. In Proceedings of The Second Annual Conference on Wireless On-demand Network Systems and Services (pp.83-88), Switzerland. The EU Data Grid Project (n.d.). Retrieved from http://www.eu-datagrid.org/. The Globus Alliance (n.d.). Retrieved from http://www.globus.org/ Unicore (n.d.). Retrieved from http://unicore.sourceforge.net Vazhkudai, S., & Syed, J., & Maginnis T. (2002). PODOS - The design and implementation of a performance oriented Linux cluster. Future Generation Computer Systems, 18(3), 335–352. doi:10.1016/ S0167-739X(01)00055-3
KEY TERMS AND DEFINITIONS Grid Computing: A new technology has been developed to contribute to the powerful computing ability for supporting distributed computing applications. Grid Middleware: A toolkit of software between grid applications and grid fabrics provides a series of functionalities including grid security infrastructure, data management, job management, and information services. The Grid Resource Allocation and Management (GRAM): GRAM provides a series of uniform interfaces to simplify the access of remote grid resources for job execution. Grid Security Infrastructure (GSI): It provides the authentication and authorization mechanisms for system protection according to X.509 proxy certificates. GridFTP: A securer file transmission protocol in grid computing. Pervasive Grid: A novel grid architecture that enables users to manipulate grid services transparently. Replica Location Service (RLS): RLS maintains the location information of replicas from logical file names (LFN) to physical file names (PFN).
13
14
Chapter 2
Pervasive Grids
Challenges and Opportunities Manish Parashar Rutgers, The State University of New Jersey, USA Jean-Marc Pierson Paul Sabatier University, France
ABSTRACT Pervasive Grid is motivated by the advances in Grid technologies and the proliferation of pervasive systems, and is leading to the emergence of a new generation of applications that use pervasive and ambient information as an integral part to manage, control, adapt and optimize. However, the inherent scale and complexity of Pervasive Grid systems fundamentally impact how applications are formulated, deployed and managed, and presents significant challenges that permeate all aspects of systems software stack. In this chapter, the authors present some use-cases of Pervasive Grids and highlight their opportunities and challenges. They then present why semantic knowledge and autonomic mechanisms are seen as foundations for conceptual and implementation solutions that can address these challenges.
INTRODUCTION Grid computing has emerged as the dominant paradigm for wide-area distributed computing (Parashar & Lee, 2005). The goal of the original Grid concept is to combine resources spanning many organizations into virtual organizations that can more effectively solve important scientific, engineering, business and government problems. Over the last decade, significant resources and research efforts have been devoted towards making this vision a reality and have lead to the development and deployment of a number of Grid infrastructures targeting a variety of applications. However, recent technical advances in computing and communication technologies and associated cost dynamics are rapidly enabling a ubiquitous and pervasive world - one in which the everyday objects surrounding us have embedded computing and communication capabilities and form a seamless Grid of DOI: 10.4018/978-1-60566-661-7.ch002
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Pervasive Grids
information and interactions. As these technologies weave themselves into the fabrics of everyday life (Weiser, 1991), they have the potential of fundamentally redefining the nature of applications and how they interact with and use information. This leads to a new revolution in the original Grid concept and the realization of a Pervasive Grid vision. The Pervasive Grid vision is driven by the advances in Grid technologies and the proliferation of pervasive systems, and seamlessly integrates sensing/actuating instruments and devices together with classical high performance systems as part of a common framework that offers the best immersion of users and applications in the global environment. This is, in turn, leading to the emergence of a new generation of applications using pervasive and ambient information as an integral part to manage, control, adapt and optimize (Pierson, 2006; Matossian et al., 2005; Bangerth, Matossian, Parashar, Klie, &Wheeler, 2005; Parashar et al., 2006). These applications include a range of application areas including crisis management, homeland security, personal healthcare, predicting and managing natural phenomenon, monitoring and managing engineering systems, optimizing business processes, etc (Baldridge et al., 2006). Note that it is reasonable to argue that in concept, the vision of Pervasive Grids was inherent in the visions of “computing as a utility” originally by Corbat et al (Corbat & Vyssotsky, 1965) and later by Foster et al (Foster, Kesselman, & Tuecke, 2001). In this sense, Pervasive Grids are the next significant step towards realizing the metaphor of the power grid. Furthermore, while, Foster et al., defined a computational Grid in (Foster & Kesselman, 1999) as “... a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities”, the term pervasive in this definition refers to the transparent access to resources rather than the nature of the resources themselves. Pervasive Grids focus on the latter and essentially address an extreme generalization of Grid concept where the resources are pervasive and include devices, services, information, etc. The aim of this chapter is to introduce the vision of Pervasive Grid computing and to highlight its opportunities and challenges. In this paper we first described the nature of applications in a Pervasive Grid and outline their requirements. We then describe key research challenges, and motivate semantic knowledge and autonomic mechanisms as the foundations for conceptual and implementation solutions that can address these challenges.
PERVASIVE GRID APPLICATIONS AND THEIR REqUIREMENTS The applications enabled by Pervasive Grid systems can be classified along three broad axes based on their programming and runtime requirements. Opportunistic applications can discover and use available pervasive information and resources, to potentially adapt, optimize, improve QoS, provide a better user experience, etc. For example, a navigation system may use real-time traffic information (possibly obtained from other vehicles) to reduce or avoid congested routes. Similarly, a vehicle safety system may use information from oncoming vehicles to appropriately warn the driver of possible hazards. A key characteristic of these applications is that they do not depend on the availability of the information, but can opportunistically use information if it is available. Note that this application may consume raw information and process it locally. Alternately, they may “outsource” the processing of information using available resources at the source of the information or within the pervasive environment. While the above applications are centered on a single user, in cooperative applications, multiple application entities (possibly wireless devices) cooperate with each other, each providing partial information, to make collective decisions in an autonomous manner. An example is a swarm of wireless robotic devices cooperatively
15
Pervasive Grids
exploring a disaster site or a group of cars sharing information to estimate the overall traffic situation. Finally, certain control applications provide autonomic control capabilities using actuation devices in addition to sensors, for example, a car may anticipate traffic/road conditions and appropriately apply the brakes. As an illustration consider the somewhat futuristic use-case scenario presented below that describes how an international medical emergency may be handled using the “anytime-anywhere” access to information and services provided by a Pervasive Grid. This scenario shares some of the views of (Akogrimo, 2004) while adding the semantic dimension to the process. Mr. Smith lives in Toulouse, France, and leaves for a few days to Vienna, Austria. Unfortunately, on the way, he is involved in an accident leaving him lying unconscious on the road. When help arrives, they only find a single piece of information on Mr. Smith, i.e., a numerical identifier (for example on a smart card), which allows the helps to quickly access Mr. Smith’s medical file (which is at least partially in France, perhaps in Toulouse), to find important information (for example, details of drug allergies, of its operational antecedents - was already anesthetized, with which product? did he have an operation? are there records available such as an operation report or x-rays?) that will allow the responders to adapt and customize the care given to Mr. Smith.
Let us consider this use-case in detail. First, let us assume (unrealistically) that the problem of the single identifier is solved (this particular point is a subject political, ethical, and is far from being solved, even at the European scale), and that Mr. Smith has a health card that encodes his identifier. Pervasive sensors are already embedded with Mr. Smith to monitor his blood pressure and sugar rate in his blood. These data are available through a specific application available for a range of devices (Palm, notebooks,...) and transmitted via WiFi from the sensors to the application devices. Further, Mr. Smith’s medical data is distributed across various medical centers. The contents of the medical files must be accessible in a protected way: Only authorized individuals should be able to access relevant parts of the file, and ideally these authorizations are given by Mr. Smith himself. Note that all the documents would be naturally in French and possibly in different formats and modalities.
Now, the Austrian responder, who only speaks German, has a Palm, with WiFi connection. The WiFi hot spot is located in the ambulance and allows the responder to consult patient medical records through a public hospital network. The intervention by the responder begins on the spot of the accident and continues on the road towards the hospital. Please note that at this stage, the responder has no idea of the pervasive presence of the sensors embedded with Mr. Smith. When the responder wants to access information about allergies to certain medication, he should initially know where this information resides. From both the identifier of Mr. Smith and the request itself (allergies?), the system seeks the storage centers likely to have some information about Mr. Smith. The responder contacts these centers. He also needs to obtain authorization to enter the French information systems, which he obtains by starting from his certificate of membership to the health Austrian system. Trust certificates are established to allow him to access the network of care where the required data are.
16
Pervasive Grids
An integration service must transform the responder’s request to be compatible with the schema of the databases containing the relevant information, and negotiates, according to his profile and of the presented request, the parts of the database accessible to him. The request is expressed using a common vocabulary and semantic (ontology of the medical field) representation to get around the language issue. To reach the data itself, the responder presents the mandatory certificates to read the files. Mr. Smith must have previously created certificates for standard accesses to some of his data, for example, the people being able to endorse the responders role can access information about drug allergies. A repository of the standard certificates for Mr. Smith must be accessible on line. The responder presents the retrieved certificates which authorizes the access and returns the data.
After this interaction, two kinds of information are available: First, the system alerts the responder of the presence of sensors with Mr. Smith, and starts the download of the appropriate application (graphic and language interface must be adapted) on its Palm. Thanks to the retrieved information, the responder knows the sugar rate in the blood. The second kind of information is related to the medical records of Mr. Smith. The metadata of the documents are analyzed to know their nature and to see how the Palm can exploit them. An adaptation service is probably required, to create a chain of transformation from the original documents (in written and spoken French) into documents that can be used by the responder currently in the moving ambulance, where he can only read and not listen (due to the noisy environment). Appropriate services include a service for audio-to-text transformation, a French-German translation service, etc. Finally, the first-aid worker gets the relevant data and administers the appropriate medication to the patient.
During the transportation, information about patient (drugs, known allergies, identifier of the patient) are transmitted to the hospital. In the hospital, even before the arrival of the ambulance, a surgeon can recover, using similar mechanisms but with different conditions (less constrained terminal, higher role in the care network, etc.), more complete information (operational antecedents, scanner, etc.) in order to be able to intervene appropriately. The surgeon can decide to start some more complex computation on the data he retrieved like comparing this patient characteristics (and data, such as images, analysis, etc.) to a patient database to better suit this particular patient case and provide personalized help. This may lead to use utility computing facilities on a stable infrastructure. In the scenario, the responder is very active, interacting with the local sensors and the global infrastructure. One should understand that much of the tasks should be automated, delegated and performed transparently by his device. The pervasive grid ecosystem, which integrates computers, networks, data archives, instruments, observatories, experiments, and embedded sensors and actuators, is also enabling new paradigms in science and engineering - ones that are information/data-driven and that symbiotically and opportunistically combines computations, experiments, observations, and real-time information to understand and manage natural and engineering systems. For example, an Instrumented Oil-Field can (theoretically) achieve efficient and robust control and management of diverse subsurface and near subsurface geo-systems by completing the symbiotic feedback loop between measured data and a set of computational models, and can provide efficient,
17
Pervasive Grids
cost-effective and environmentally safe production of oil reservoirs. Similar strategies can be applied to CO2 sequestration, contaminated site cleanup, bio-landfill optimization, aquifer management and fossil fuel production. Another example application is the modelling and understanding of complex marine and coastal phenomena, and the associated management and decision-making processes. This involves an observational assessment of the present state, and a scientific understanding of the processes that will evolve the state into the future, and requires combining surface remote sensing mechanisms (satellites, radar) and spatially distributed in situ subsurface sensing mechanisms to provide a well sampled blueprint of the ocean, and coupling this real-time data with modern distributed computational models and experiments. Such a pervasive information-driven approach is essential to address important national and global challenges such as (1) safe and efficient navigation and marine operations, (2) efficient oil and hazardous material spill trajectory prediction and clean up, (3) monitoring, predicting and mitigating coastal hazards, (4) military operations, (5) search and rescue, and (6) prediction of harmful algal blooms, hypoxic conditions, and other ecosystem or water quality phenomena. For example, underwater and aerial robots and oceanic observatories can provide real-time data which, coupled with online satellite, radar and historical data, advanced models and computational and data-management systems, can be used to predict and track extreme weather and coastal behaviours, manage atmospheric pollutants and water contaminants (oil spills), perform underwater surveillance, study coastal changes, track hydrothermal plumes (black smokers), and study the evolution of marine organisms and microbes. An area where pervasive grids can potentially impact in a dramatic way is crisis management and response where immediate and intelligent responses to a rapidly changing situation could mean the difference between life and death for people caught up in a terrorist or other crisis situation. For example, a prototype disaster response test bed, which combines information and data feeds from an actual evolving crisis event with a realistic simulation framework (where the on-going event data are continually and dynamically integrated with the on-line simulations), can provide the ability for decision support and crisis management of real situations as well as more effective training of first-responders. Similarly, one can conceive of a fire management application where computational models use streaming information from sensors embedded in the building along with real time and predicted weather information (temperature, wind speed and direction, humidity) and archived history data to predict the spread of the fire and to guide fire-fighters, warning of potential threats (blowback if a door is opened) and indicating most effective options. This information can also be used to control actuators in the building to manage the fire and reduce damage.
CROSSCUTTING CHALLENGES The Pervasive Grid environment is inherently large, heterogeneous and dynamic, globally aggregating large numbers of independent computing and communication resources, data stores, instruments and sensing/actuating devices. The result is an unprecedented level of uncertainty that is manifested in all aspects of the Pervasive Grid: System, Information and Application (Parashar & Browne, 2005; Parashar, 2006). •
18
System uncertainty reflects in its structure (e.g., flat, hierarchical, P2P, etc.), in the dynamism of its components (entities may enter, move or leave independently and frequently), in the heterogeneity
Pervasive Grids
• •
of its components (their connectivity, reliability, capabilities, cost, etc.), in the lack of guarantees, and more importantly, in the lack of common knowledge of numbers, locations, capacities, availabilities and protocols used by its constituents. Information uncertainty is manifested in its quality, availability, compliance with common understanding and semantics, as well the trust in its source. Finally, application uncertainty is due to the scale of the applications, the dynamism in application behaviours, and the dynamism in its compositions, couplings and interactions (services may connect to others on a dynamic and opportunistic way).
The scale, complexity, heterogeneity, and dynamism of Pervasive Grid environments and the resulting uncertainty present thus requires that the underlying technologies, infrastructures and applications must be able to detect and dynamically respond during execution to changes in the state of execution environment, the state and requirements of the application and the overall context of the applications. This requirement suggests that (Parashar & Browne, 2005): 1. 2.
3.
Applications should be composed from discrete, self-managing components which incorporate separate specifications for all of functional, non-functional and interaction-coordination behaviours. The specifications of computational (functional) behaviours, interaction and coordination behaviours and non-functional behaviours (e.g. performance, fault detection and recovery, etc.) should be separated so that their combinations are composable. The interface definitions of these components should be separated from their implementations to enable heterogeneous components to interact and to enable dynamic selection of components.
Given these features, a Pervasive Grid application requiring a given set of computational behaviours may be integrated with different interaction and coordination models or languages (and vice versa) and different specifications for non-functional behaviours such as fault recovery and QoS to address the dynamism and heterogeneity of the application and the underlying environments.
RESEARCH OPPORTUNITIES IN PERVASIVE GRID COMPUTING We believe that addressing the challenges outlined above requires new paradigm for realizing the Pervasive Grid Infrastructure and its technologies that is founded on semantic knowledge and autonomic mechanisms (Parashar & Browne, 2005; Parashar, 2006). Specifically: 1. 2. 3. 4.
Static (defined at the time of instantiation) application requirements, system and application behaviours to be relaxed The behaviours of elements and applications to be sensitive to the dynamic state of the system and the changing requirements of the application and to be able to adapt to these changes at runtime, Common knowledge to be expressed semantically (ontology and taxonomy) rather than in terms of names, addresses and identifiers, The core enabling middleware services (e.g., discovery, coordination, messaging, security) to be driven by such a semantic knowledge. Further the implementations of these services must be resilient and must scalably support asynchronous and decoupled behaviours.
19
Pervasive Grids
Key research challenges includes: •
•
•
20
Programming models, abstractions and systems: Applications targeted to emerging Pervasive Grids must be able to address high levels of uncertainty inherent in these environments, and require the ability to discover, query, interact with, and control instrumented physical systems using semantically meaningful abstractions. As a result, they require appropriate programming models and systems that support notions of dynamic space-time context, as well as enable applications capable of correctly and consistently adapting their behaviours, interactions and compositions in real time in response to dynamic data and application/system state, while satisfying real time, functional, performance, reliability, security, and quality of service constraints. Furthermore, since these behaviours and adaptations are context dependent, they need to be specified separately and at runtime, and must consistently and correctly orchestrate appropriate mechanisms provided by the application components to achieve autonomic management. Data/information quality/uncertainty management: A key issue in pervasive systems is the characterization of the quality of information and the need of estimating its uncertainty, so that it can effectively drive the decision making process. This includes algorithms and mechanisms to synthesize actionable information with dynamic qualities and properties from streams of data from the physical environment, and address issues of data quality assurance, statistical synthesis and hypotheses testing, and in-network data assimilation, spatial and/or temporal multiplexing, clustering and event detection. Works done in the field of data management (Dong, Halevy, & Yu, 2007; Benjelloun, Sarma, Halevy, Theobald, & Widom, 2008) gives some hints on how to handle the data integration when the certainty of individual sources is not sure. Another related aspect is providing mechanisms for adapting the level and frequency of sensing based on this information. Achieving this in an online and in-network manner (as opposed to post-processing stored data) with strict space-time constraints presents significant challenges, wich are not addressed by most existing systems. Note that, since different in-network data processing algorithms will have different cost/performance behaviours, strategies for adaptive management of tradeoffs so as to optimize overall application requirements are required. Systems software and runtime & middleware services: Runtime execution and middleware services have to be extended to support context-/content-/location-aware and dynamic, data/ knowledge-driven and time-constrained executions, adaptations, interactions, compositions of application elements and services, while guaranteeing reliable and resilient execution and/ or predictable and controllable performances. Furthermore, data acquisition, assimilation and transport services have to support seamless acquisition of data from varied, distributed and possibly unreliable data sources, while addressing stringent real-time, space and data quality constraints. Similarly, messaging and coordination services must support content-based scalable and asynchronous interactions with different service qualities and guarantees. Finally, sensor system management techniques are required for the dynamic management of sensor systems including capacity and energy aware topology management, runtime management including adaptations for computation/communication/power tradeoffs, dynamic load-balancing, and sensor/actuator system adaptations.
Pervasive Grids
RELATED WORK Research Landscape in Grid and Autonomic Computing Grid computing research efforts over the last decade can be broadly divided into efforts addressing the realization of virtual organizations and those addressing the development of Grid applications. The former set of efforts have focused on the definition and implementation of the core services that enable the specification, construction, operation and management of virtual organizations and instantiation of virtual machines that are the execution environments of Grid applications. Services include: •
• •
• •
Security services to enable the establishment of secure relationships between a large number of dynamically created subjects and across a range of administrative domains, each with its own local security policy, Resource discovery services to enable discovery of hardware, software and information resources across the Grid, Resource management services to provide uniform and scalable mechanisms for naming and locating remote resources, support the initial registration/discovery and ongoing monitoring of resources, and incorporate these resources into applications, Job management services to enable the creation, scheduling, deletion, suspension, resumption, and synchronization of jobs, Data management services to enable accessing, managing, and transferring of data, and providing support for replica management and data filtering.
Efforts in this class include Globus (The Globus Alliance), Unicore (Unicore Forum), Condor (Thain, Tannenbaum, & Livny, 2002) and Legion (Grimshaw & Wulf, 1997). Other efforts in this class include the development of common APIs, toolkits and portals that provide high-level uniform and pervasive access to these services. These efforts include the Grid Application Toolkit (GAT) (Allen et al., 2003), DVC (Taesombut & Chien, 2004) and the Commodity Grid Kits (CoG Kits) (Laszewski, Foster, & Gawor, 2000). These systems often incorporate programming models or capabilities for utilizing programs written in some distributed programming model. For example, Legion implements an object-oriented programming model, while Globus provides a capability for executing programs utilizing message passing. The second class of research efforts deals with the formulation, programming and management of Grid applications. These efforts build on the Grid implementation services and focus on programming models, languages, tools and frameworks, and application runtime environments. Research efforts in this class include GrADS (Berman et al., 2001), GridRPC (Nakada et al., 2003), GridMPI (Ishikawa, Matsuda, Kudoh, Tezuka, & Sekiguchi, 2003), Harness (Migliardi & Sunderam, 1999), Satin/IBIS (Nieuwpoort, Maassen, Wrzesinska, Kielmann, & Bal, 2004) (Nieuwpoort et al., n.d.), XCAT (Govindaraju et al., 2002) (Krishnan & Gannon, 2004), Alua (Ururahy & Rodriguez, 2004), G2 (Kelly, Roe, & Sumitomo, 2002), J-Grid (Mathe, Kuntner, Pota, & Juhasz, 2003), Triana (Taylor, Shields, Wang, & Philp, 2003), and ICENI (Furmento, Hau, Lee, Newhouse, & Darlington, 2003). These systems have essentially built on, combined and extended existing models for parallel and distributed computing. For example, GridRPC extends the traditional RPC model to address system dynamism. It builds on Grid system services to combines resource discovery, authentication/authorization, resource allocation and task
21
Pervasive Grids
scheduling to remote invocations. Similarly, Harness and GridMPI build on the message passing parallel computing model, Satin supports divide-and-conquer parallelism on top of the IBIS communication system. GrADS builds on the object model and uses reconfigurable object and performance contracts to address Grid dynamics, XCAT and Alua extend the component based model. G2, J-Grid, Triana and ICENI build on various service based models. G2 builds on .Net (Microsoft .Net), J-Grid builds on Jini (Jini Network Technology) and current implementations of Tirana and ICENI build on JXTA (Project JXTA, 2001). While this is natural, it also implies that these systems implicitly inherit the assumptions and abstractions that underlie the programming models of the systems upon which they are based and thus in turn inherit their assumptions, capabilities and limitations. In the last years, the semantic grid paradigm has gained much interests from authors and at the Global Grid forum. In (De Roure, Jennings, & Shadbolt, 2005), De Roure and Jennings propose a view on semantic grid its past, present and future. The identify some key requirements of the semantic grid: Resource description discovery and use, process description and enactment, security and trust, annotation to enrich the description of digital content, information integration and fusion (potentially on the fly), context awareness, communities, smart environments, ... Ontologies, semantic web services are entitled to give some help to achieve a semantic grid. Works on semantic grid can be enlarged to encompass pervasive computing (Roure, 2003). In this work, the author defines where semantic grid can benefit from pervasive devices, and vice-versa: Indeed on one side the semantic grid can benefit to the processing of the data acquired for instance by sensors, on the other hand, the semantic grid benefits from potential metadata coming from the pervasive appliances themselves allowing for the automatic creation of annotation describing them. There has also been research by the authors and other on applying Autonomic Computing (Kephart & Chess, 2003; Parashar & Hariri, 2006) concepts to Grid systems and applications. The autonomic computing paradigm is inspired by biological systems, and aims at developing systems and applications that can manage and optimize themselves using only high-level guidance. The key concept is a separation of (management, optimization, fault-tolerance, security) policies from enabling mechanisms, allowing a repertoire of mechanisms to operate at runtime to respond to the heterogeneity and dynamics, both of the applications and the infrastructure. This enables undesired changes in operation to trigger changes in the behaviourof the computing system to respond to the changes, so that the system continues to operate (or possibly degrades) in a conformant manner - for example,the system may recover from faults, reconfigure itself to match its environment, and maintainits operations at a near optimal performance. Autonomic techniques have be applied to various aspects of Grid computing such as application runtime management, workloadmanagement and data distribution, data steaming and processing, etc. (Parashar & Hariri,2006). As we will see in the next part, these works on semantically enhanced grids and autonomic computing are complimentary to other works directly related to the presence of mobile and context aware appliances in the environment. Most of these works do not deal with all the specificities of Pervasive Grids. We now detail some works in that specific directions.
Pervasive Grid Efforts Davies, Storz and Friday (Storz, Friday, & Davies, 2003; Davies, Friday, & Storz, 2004) were among the first to introduce the concept of “Ubiquitous Grid”, that is close to our Pervasive Grid vision. The purpose of their research paper is to compare the notion of Grid Computing (definition of I. Foster (Fos-
22
Pervasive Grids
ter, Kesselman, Nick, & Tuecke, 2002)) and the notion of Pervasive Systems (definition of M. Weiser (Weiser, 1991)). They identify similar interests: heterogeneity, interoperability, scalability, adaptability and fault tolerance, resources management, services composition, discovery, security, communication, audit, payment. They then briefly present a use-case for a ubiquitous Grid, which they develop using Globus Toolkit 3 (GT3). Lack of details makes it difficult to evaluate exactly what has been done to make GT3 behave as a an ubiquitous Grid, and what aspects of ubiquity has been addressed. Hingne et al. (Hingne, Joshi, Finin, Kargupta, & Houstis, 2003) propose a multi-agent approach to realize a P-Grid. They are primarily interested in communication, heterogeneity, discovery and services composition, and scheduling of tasks between the different devices constituting the P-Grid. McKnight et al. (McKnight, Howison, & Bradner, 2004) introduce the concept of a Wireless Grid. Their interest is in the mobile and nomadic issues, which they compare with traditional computing Grids, P2P networks and web services. An interesting aspect of this article is that it investigates the relationships between these actors. In the article, the authors focus on services that they identify as the most important, i.e., resources description and discovery, coordination, trust management and access control. In (Srinavisan, 2005), S.H. Srinivasan details a Wireless Pervasive Grid architecture. The author separates Grid in two parts: the “backbone grid”, physically linked and analogous to network backbones, and the wireless “access grid”. Agents realize the proxy between the two grids, and act on behalf of mobile devices in the “access grid” on the “backbone grid”. Interesting aspects of this effort are the pro-activity and context-awareness of the presentation to end-users. Coulson et al. (Coulson et al., 2005) present a middleware structured using a lightweight run-time component model (OpenCom) that enables appropriate profiles to be configured on a wide range of device types, and facilitates runtime reconfiguration (as required to adapt to dynamic environments). More recently, Coronato and De Pietro (Coronato & Pietro, 2007) describe MiPEG, a middleware consisting of a set of services (compliant to grid standard OGSA) enhancing classic Grid environments (namely the Globus Toolkit) with mechanisms for handling mobility, context-awareness, users’ session and distribution of tasks on the users’ computing facilities. Complementary to these, existing research efforts have tackled aspects of integrating pervasive systems with computing Grids, primarily in the fields of mobile computing and pervasive computing. They include works on interaction, mobility and context adaptation. Research presented in (Allen et al., 2003; Graboswki, Lewandowski, & Russell, 2004; Gonzalez-Castano, Vales-Alonso, Livny, Costa-Montenegro, & Anido-Rifo, 2003) focused on the use of light devices to interact with computing Grids, e.g., submitting jobs and visualizing results. A closer integration of mobile devices with the Grids is addressed in (Phan, Huang, & Dulan, 2002; Park, Ko, & Kim, 2003), which proposes proxy services to distribute and organize jobs among a pool of light devices. The research presented in (Kurkovsky, Bhagyavati, Ray, & Yang, 2004) solicits surrounding devices to participate in a problem-solving environment. Mobile Grids have received much interest in the last years with the development of ad hoc networks and/or IPv6 and the works in the mobile computing field. Some researchers (Chu & Humphrey, 2004; Clarke & Humphrey, 2002) have investigated how a Grid middleware (Legion, OGSI.NET) can be adapted to tackle mobility issues. In (Litke, Skoutas, & Varvarigou, 2004), the authors present the opportunities of research challenges in resource management in mobile grid environments, namely resource discovery and selection, job management from scheduling, replication, to migration and monitoring, and replica management. (Li, Sun, & Ifeachor, 2005) gives some challenges of mobile ad-hoc network and adds a Quality of Service dimension to previous works, including provisioning and continuity of service, latency, energy constraints, and fault tolerance in general. The authors map their observations to a mobile
23
Pervasive Grids
healthcare scenario. (Oh, Lee, & Lee, 2006) proposes in a wireless world to allocate dynamically the tasks to surroundings resources, taking into account the context of these resources (their possibilities in terms of resources: energy, network, CPU power,...). In (Waldburger & Stiller, 2006) the authors focus on the provisioning of services in mobile grids and compare business and technical metrics between Grid Computing, Service Grid, mobile and knowledge grids, SOA and P2P systems. They extend the vision of classical Virtual Organizations to Mobile Dynamic VO. Mobile agents are used in (Guo, Zhang, Ma, & Zhang, 2004; Bruneo, Scarpa, Zaia, & Puliafito, 2003; Baude, Caromel, Huet, & Vayssiere, 2000) to migrate objects and codes among the nodes while (Wang, Yu, Chen, & Gao, 2005) apply mobile agents to MANET with dynamic and ever changing neighbors. (Wong & Ng, 2006) focus on security while combining mobile agents and the Globus grid middleware to handle mobile grid services. (Akogrimo, 2004; Jiang, O’Hanlon, & Kirstein, 2004) are interested in the advantages of mobility features of IPv6 in the notification and adaptation of Grids. The authors of (Messig & Goscinski, 2007) relate their work on autonomic system management in mobile grid environment, encompassing the self discovery, selfconfiguration and dynamic deployment and self healing for fault tolerance. Context-awareness is the primary focus of the work presented in (Jean, Galis, & Tan, 2004). The authors present an extension of virtual organization to context, providing personalization of the services. In (Zhang & Parashar, 2003), the authors propose a context aware access control in grids. (Yamin et al., 2003; Otebolaku, Adigun, Iyilade, & Ekabua, 2007) include mobility and context-awareness in their presentation.
CONCLUSION The proliferation of pervasive sensing/actuating devices coupled with advances in computing and communication technologies are rapidly enabling the next revolution in Grid computing - the emergence of Pervasive Grids. This, in turn, is enabling a new generation of application that use pervasive information and services to manage, control, adapt and optimize natural and engineering real-world systems. However, the inherent scale and complexity of Pervasive Grid systems fundamentally impact the nature of applications and how they are formulated, deployed and managed, and presents significant challenges that permeate all aspects of systems software stack from applications to programming models and systems to middleware and runtime services. This paper outlined the vision of Pervasive Grid Computing along with its opportunities and challenges, and presented a research agenda for enabling this vision.
REFERENCES Allen, G., Davis, K., Dolkas, K. N., Doulamis, N. D., Goodale, T., Kielmann, T., et al. (2003). Enabling applications on the grid: A Gridlab overview. International Journal of High Performance Computing Applications: Special issue on Grid Computing: Infrastructure and Applications. Baldridge, K., Biros, G., Chaturvedi, A., Douglas, C. C., Parashar, M., How, J., et al. (2006, January). National Science Foundation DDDAS Workshop Report. Retrieved from http://www.dddas.org/nsfworkshop-2006/wkshp report.pdf.
24
Pervasive Grids
Bangerth, W., Matossian, V., Parashar, M., Klie, H., & Wheeler, M. (2005). An autonomic reservoir framework for the stochastic optimization of well placement. Cluster Computing, 8(4), 255–269. doi:10.1007/s10586-005-4093-3 Baude, F., Caromel, D., Huet, F., & Vayssiere, J. (2000, May). Communicating mobile active objects in java. In R. W. Marian Bubak Hamideh Afsarmanesh & B. Hetrzberger (Eds.), Proceedings of HPCN Europe 2000 (Vol. 1823, p. 633-643). Berlin: Springer. Retrieved from http://www-sop.inria.fr/oasis/ Julien.Vayssiere/publications/18230633.pdf Benjelloun, O., Sarma, A. D., Halevy, A. Y., Theobald, M., & Widom, J. (2008). Databases with uncertainty and lineage. The VLDB Journal, 17(2), 243–264. doi:10.1007/s00778-007-0080-z Berman, F., Chien, A., Cooper, K., Dongarra, J., Foster, I., & Gannon, D. (2001). The grads project: Software support for high-level grid application development. International Journal of High Performance Computing Applications, 15(4), 327–344. doi:10.1177/109434200101500401 Bruneo, D., Scarpa, M., Zaia, A., & Puliafito, A. (2003). Communication paradigms for mobile grid users. In CCGRID 03 (p. 669). Chu, D., & Humphrey, M. (2004, November 8). Bmobile ogsi.net: Grid computing on mobile devices. In Grid computing workshop (associated with supercomputing 2004), Pittsburgh, PA. Clarke, B., & Humphrey, M. (2002, April 19). Beyond the ”device as portal”: Meeting the requirements of wireless and mobile devices in the legion grid computing system. In 2nd International Workshop On Parallel And Distributed Computing Issues In Wireless Networks And Mobile Computing (associated with ipdps 2002), Ft. Lauderdale, FL. Corbat, F. J., & Vyssotsky, V. A. (1965). Introduction and overview of the multics system. FJCC, Proc. AFIPS, 27(1), 185–196. Coronato, A., & Pietro, G. D. (2007). Mipeg: A middleware infrastructure for pervasive grids. Journal of Future Generation Computer Systems. Coulson, G., Grace, P., Blair, G., Duce, D., Cooper, C., & Sagar, M. (2005, April). A middleware approach for pervasive grid environments. In Uk-ubinet/ uk e-science programme workshop on ubiquitous computing and e-research. Davies, N., Friday, A., & Storz, O. (2004). Exploring the grid’s potential for ubiquitous computing. IEEE Pervasive Computing / IEEE Computer Society [and] IEEE Communications Society, 3(2), 74–75. doi:10.1109/MPRV.2004.1316823 De Roure, D., Jennings, N., & Shadbolt, N. (2005, March). The semantic grid: Past, present, and future. Proceedings of the IEEE, 93(3), 669–681. doi:10.1109/JPROC.2004.842781 Dong, X., Halevy, A. Y., & Yu, C. (2007). Data integration with uncertainty. In Vldb ’07: Proceedings of the 33rd International Conference on Very Large Data Bases (pp. 687–698). VLDB Endowment. Foster, I., & Kesselman, C. (Eds.). (1999). The grid: Blueprint for a new computing infrastructure. San Francisco: Morgan Kaufmann Publishers, Inc.
25
Pervasive Grids
Foster, I., Kesselman, C., Nick, J., & Tuecke, S. (2002). The physiology of the grid: An open grid services architecture for distributed systems integration. Retrieved from citeseer.nj.nec.com/foster02physiology. html Foster, I., Kesselman, C., & Tuecke, S. (2001). The anatomy of the grid: Enabling scalable virtual organizations. The International Journal of Supercomputer Applications, 15(3), 200–222. Furmento, N., Hau, J., Lee, W., Newhouse, S., & Darlington, J. (2003). Implementations of a serviceoriented architecture on top of jini, jxta and ogsa. In Proceedings of uk e-science all hands meeting. Gonzalez-Castano, F. J., Vales-Alonso, J., Livny, M., Costa-Montenegro, E., & Anido-Rifo, L. (2003). Condor grid computing from mobile handheld devices. SIGMOBILE Mobile Comput. Commun. Rev., 7(1), 117–126. doi:10.1145/881978.882005 Govindaraju, M., Krishnan, S., Chiu, K., Slominski, A., Gannon, D., & Bramley, R. (2002, June). Xcat 2.0: A component-based programming model for grid web services (Tech. Rep. No. Technical ReportTR562). Dept. of C.S., Indiana Univ., South Bend, IN. Graboswki, P., Lewandowski, B., & Russell, M. (2004). Access from j2me-enabled mobile devices to grid services. In Proceedings of Mobility Conference 2004, Singapore. Grimshaw, A. S., & Wulf, W. A. (1997). The legion vision of a worldwide virtual computer. Communications of the ACM, 40(1), 39–45. doi:10.1145/242857.242867 Guo, S.-F., Zhang, W., Ma, D., & Zhang, W.-L. (2004, Aug.). Grid mobile service: using mobile software agents in grid mobile service. Machine learning and cybernetics, 2004. In Proceedings of 2004 International Conference on, 1, 178-182. Hingne, V., Joshi, A., Finin, T., Kargupta, H., & Houstis, E. (2003). Towards a pervasive grid. In International parallel and distributed processing symposium (ipdps’03) (p. 207). Ishikawa, Y., Matsuda, M., Kudoh, T., Tezuka, H., & Sekiguchi, S. (2003). The design of a latency-aware mpi communication library. In Proceedings of swopp03. Jean, K., Galis, A., & Tan, A. (2004). Context-aware grid services: Issues and approaches. In Computational science–iccs 2004: 4th international conference Krak’ow, Poland, June 6–9, 2004, proceedings, part iii (LNCS Vol. 3038, p. 1296). Berlin: Springer. Jiang, S., O’Hanlon, P., & Kirstein, P. (2004). Moving grid systems into the ipv6 era. In Proceedings of Grid And Cooperative Computing 2003 (LNCS 3033, pp. 490–499). Heidelberg, Germany: SpringerVerlag. Kelly, W., Roe, P., & Sumitomo, J. (2002). G2: A grid middleware for cycle donation using. net. In Proceedings of the 2002 International Conference on Parallel and Distributed Processing Techniques and Applications. Kephart, J. O., & Chess, D. M. (2003). The vision of autonomic computing. Computer IEEE Computer Society, 36(1), 41–50.
26
Pervasive Grids
Krishnan, S., & Gannon, D. (2004). Xcat3: A framework for cca components as ogsa services. In Proceedings of Hips 2004, 9th International Workshop on High-Level Parallel Programming Models and Supportive Environments. Kurkovsky, S. Bhagyavati, Ray, A., & Yang, M. (2004). Modeling a grid-based problem solving environment for mobile devices. In ITCC (2) (p. 135). New York: IEEE Computer Society. Laszewski, G. v., Foster, I., & Gawor, J. (2000). Cog kits: A bridge between commodity distributed computing and high-performance grids. In ACM 2000 Conference on java grande (p.97 - 106). San Francisco, CA: ACM Press. Li, Z., Sun, L., & Ifeachor, E. (2005). Challenges of mobile ad-hoc grids and their applications in ehealthcare. In Proceedings of Second International Conference on Computational Intelligence in Medicine And Healthcare (cimed’ 2005). Litke, A., Skoutas, D., & Varvarigou, T. (2004). Mobile grid computing: Changes and challenges of resource management in a mobile grid environment. In Proceedings of Practical Aspects of Knowledge Management (PAKM 2004), Austria. Mathe, J., Kuntner, K., Pota, S., & Juhasz, Z. (2003). The use of jini technology in distributed and grid multimedia systems. In MIPRO 2003, Hypermedia and Grid Systems (p. 148-151). Opatija, Croatia. Matossian, V., Bhat, V., Parashar, M., Peszynska, M., Sen, M., & Stoffa, P. (2005). Autonomic oil reservoir optimization on the grid. [John Wiley and Sons.]. Concurrency and Computation, 17(1), 1–26. doi:10.1002/cpe.871 McKnight, L., Howison, J., & Bradner, S. (2004, July). Wireless grids, distributed resource sharing by mobile, nomadic and fixed devices. IEEE Internet Computing, 8(4), 24–31. doi:10.1109/MIC.2004.14 Messig, M., & Goscinski, A. (2007). Autonomic system management in mobile grid environments. In Proceedings of the Fifth Australasian Symposium on ACSW Frontiers (ACSW’ 07), (pp. 49–58). Darlinghurst, Australia: Australian Computer Society, Inc. Migliardi, M., & Sunderam, V. (1999). The harness metacomputing framework. In Proceedings of Ninth Siam Conference on Parallel Processing for Scientific Computing. San Antonio, TX: SIAM. Nakada, H., Matsuoka, S., Seymour, K., Dongarra, J., Lee, C., & Casanova, H. (2003). Gridrpc: A remote procedure call api for grid computing. Nieuwpoort, R. V. v., Maassen, J., Wrzesinska, G., Hofman, R., Jacobs, C., & Kielmann, T. (2005). Ibis: a flexible and efficient Java-based Grid programming environment. Concurrency and Computation, 17(7/8), 1079-1108. Nieuwpoort, R. V. v., Maassen, J., Wrzesinska, G., Kielmann, T., & Bal, H. E. (2004). Satin: Simple and efficient Java-based grid programming. Journal of Parallel and Distributed Computing Practices. Oh, J., Lee, S., & Lee, E. (2006). An adaptive mobile system using mobile grid computing in wireless network. In Computational Science And Its Applications - ICCSA 2006 (LNCS Vol. 3984, pp. 49-57). Berlin: Springer.
27
Pervasive Grids
Otebolaku, A., Adigun, M., Iyilade, J., & Ekabua, O. (2007). On modeling adaptation in context-aware mobile grid systems. In Icas ’07: Proceedings of the Third International Conference on Autonomic And Autonomous Systems (p. 52). Washington, DC: IEEE Computer Society. Parashar, M., & Browne, J. (2005, Mar). Conceptual and implementation models for the grid. Proceedings of the IEEE, 93(3), 653–668. doi:10.1109/JPROC.2004.842780 Parashar, M., & Hariri, S. (Eds.). (2006). Autonomic grid computing concepts, requirements, infrastructures, autonomic computing: Concepts, infrastructure and applications, (pp. 49–70). Boca Raton, FL: CRC Press. Parashar, M., & Hariri, S. (Eds.). (2006). Autonomic computing: Concepts, infrastructure and applications. Boca Raton, FL: CRC Press. Parashar, M., & Lee, C. A. (2005, March). Scanning the issue: Special isssue on grid-computing. In Proceedings of the IEEE, 93 (3), 479-484. Retrieved from http://www.caip.rutgers.edu/TASSL/Papers/ proc-ieee-intro-04.pdf Parashar, M., Matossian, V., Klie, H., Thomas, S. G., Wheeler, M. F., Kurc, T., et al. (2006). Towards dynamic data-driven management of the ruby gulch waste repository. In V. N. Alexandrox & et al. (Eds.), Proceedings of the Workshop on Distributed Data Driven Applications and Systems, International Conference on Computational Science 2006 (ICCS 2006) (Vol. 3993, pp. 384–392). Berlin: Springer Verlag. Park, S.-M., Ko, Y.-B., & Kim, J.-H. (2003, December). Disconnected operation service in mobile grid computing. In First International Conference on Service Oriented Computing (ICSOC’2003), Trento, Italy. Phan, T., Huang, L., & Dulan, C. (2002). Challenge: integrating mobile wireless devices into the computational grid. In Mobicom ’02: Proceedings of the 8th annual international conference on mobile computing and networking (pp. 271–278). New York: ACM Press. Pierson, J.-M. (2006, June). A pervasive grid, from the data side (Tech. Rep. No. RR-LIRIS-2006-015). LIRIS UMR 5205 CNRS/INSA de Lyon/Universit Claude Bernard Lyon 1/Universit Lumire Lyon 2/ Ecole Centrale de Lyon. Retrieved from http://liris.cnrs.fr/publis/?id=2436 Roure, D. D. (2003). Semantic grid and pervasive computing. http://www.semanticgrid.org/GGF/ggf9/gpc/ Srinavisan, S. (2005). Pervasive wireless grid architecture. In Second annual conference on wireless on-demand network systems and services (wons’05). Storz, O., Friday, A., & Davies, N. (2003, October). Towards ‘ubiquitous’ ubiquitous computing: an alliance with ‘the grid’. In Proceedings of the First Workshop On System Support For Ubiquitous Computing Workshop (UBISYS 2003) in association with Fifth International Conference On Ubiquitous Computing, Seattle, WA. Retrieved from http://ciae.cs.uiuc.edu/ubisys/papers/alliance-w-grid.pdf Taesombut, N., & Chien, A. (2004). Distributed virtual computer (dvc): Simplifying the development of high performance grid applications. In Workshop on Grids and Advanced Networks (GAN ’04), IEEE Cluster Computing and the Grid (ccgrid2004) Conference, Chicago.
28
Pervasive Grids
Taylor, I., Shields, M., Wang, I., & Philp, R. (2003). Distributed p2p computing within triana: A galaxy visualization test case. In International Parallel and Distributed Processing Symposium (IPDPS’03). Nice, France: IEEE Computer Society Press. Thain, D., Tannenbaum, T., & Livny, M. (2002). Condor and the grid. John Wiley & Sons Inc. Ururahy, C., & Rodriguez, N. (2004). Programming and coordinating grid environments and applications. In Concurrency and computation: Practice and experience. Waldburger, M., & Stiller, B. (2006). Toward the mobile grid:service provisioning in a mobile dynamic virtual organization. In. Proceedings of the IEEE International Conference on Computer Systems and Applications, 2006, (pp.579–583). Wang, Z., Yu, B., Chen, Q., & Gao, C. (2005). Wireless grid computing over mobile ad-hoc networks with mobile agent. In Skg ’05: Proceedings of the first international conference on semantics, knowledge and grid (p. 113). Washington, DC: IEEE Computer Society. Weiser, M. (1991, February). The computer for the 21st century. Scientific American, 265(3), 66–75. Wong, S.-W., & Ng, K.-W. (2006). Security support for mobile grid services framework. In Nwesp’06: Proceedings of the international conference on next generation web services practices (pp.75–82). Washington, DC: IEEE Computer Society. Yamin, A., Augustin, I., Barbosa, J., da Silva, L., Real, R., & Cavalheiro, G. (2003). Towards merging context-aware, mobile and grid computing. International Journal of High Performance Computing Applications, 17(2), 191–203. doi:10.1177/1094342003017002008 Zhang, G., & Parashar, M. (2003). Dynamic context-aware access control for grid applications. In 4th international workshop on grid computing (grid 2003), (pp. 101 – 108). Phoenix, AZ: IEEE Computer Society Press. Retrieved from citeseer.ist.psu.edu/zhang03dynamic.html
KEY TERMS AND DEFINITIONS Autonomic Computing: Accounts for a system that does not need human intervention to work, repair, adapt and optimize. Autonomous entities must adapt to their usage context to find the best fit for their execution. Grid: The goal of the original Grid concept is to combine resources spanning many organizations into virtual organizations that can more effectively solve important scientific, engineering, business and government problems. Pervasive: A term that covers the ubiquity of the system. A pervasive system is transparent to its users that use it without noticing it. It is often linked with mobility since it helps to cover the anywhere/ anytime resources access for nomadic users. Pervasive Grid: A pervasive grid mixes a grid resource sharing with an anywhere/anytime access to these resources, either data or computing resources. Quality of Service: Designs the achievable performances that a system, an application or a service is expected to deliver to its consumers.
29
Pervasive Grids
Semantic Knowledge: Designs the enriched value of the information. Raw information coming from sensors or monitored by the system is not enough to achieve ubiquitous access to resources. Only higher level abstractions allow for handling seamlessly the system. Uncertainty: The dubiety that can be put on the system, the application or the information in a pervasive grid. Information cannot be accepted without doubt and double checking, redundancy, is often the rule.
30
31
Chapter 3
Desktop Grids
From Volunteer Distributed Computing to High Throughput Computing Production Platforms Franck Cappello INRIA and UIUC, France Gilles Fedak LIP/INRIA, France Derrick Kondo ENSIMAG - antenne de Montbonnot, France Paul Malécot Université Paris-Sud, France Ala Rezmerita Université Paris-Sud, France
ABSTRACT Desktop Grids, literally Grids made of Desktop Computers, are very popular in the context of “Volunteer Computing” for large scale “Distributed Computing” projects like SETI@home and Folding@home. They are very appealing, as “Internet Computing” platforms for scientific projects seeking a huge amount of computational resources for massive high throughput computing, like the EGEE project in Europe. Companies are also interested of using cheap computing solutions that does not add extra hardware and cost of ownership. A very recent argument for Desktop Grids is their ecological impact: by scavenging unused CPU cycles without increasing excessively the power consumption, they reduce the waste of electricity. This book chapter presents the background of Desktop Grid, their principles and essential mechanisms, the evolution of their architectures, their applications and the research tools associated with this technology.
DOI: 10.4018/978-1-60566-661-7.ch003
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Desktop Grids
ORIGINS AND PRINCIPLES Nowadays, Desktop Grids are very popular and are among the largest distributed systems in the world: the BOINC platform is used to run over 60 Internet Computing projects and scale up to 4 millions of participants. To arrive at this outstanding result, theoretical and experimental projects and researches have investigated on how to take advantage of idle CPU’s and derived the principles the of Desktop Grids.
Origins of Desktop Grids The very first paper discussing a Desktop Grid like system (Shoch & Hupp, 1982) presented the Worm programs and several key ideas that are currently investigated in autonomous computing (self replication, migration, distributed coordination, etc). Several projects preceded the very popular SETI@home. One of the first application of Desktop Grids was cracking RSA keys. Another early system, in 1997, gave the name of “distributed computing” used sometimes for Desktop Grids: distributed.net. The aim of this project was finding prime numbers using the Mersen algorithm. The folding@home project was one of the first project with SETI@home to gather thousands of participants in the first years of 2000. At that time folding@home used the COSM technology. The growing popularity of Desktop Grids has raised a significant interest in the industry. Companies like Entropia (Chien, Calder, Elbert, Bhatia, 2003), United Device1, Platform2, Mesh Technologies3 and Data Synapse have proposed Desktop Grid middleware. Performance demanding users are interested by these platforms, considering their costperformance ratio which is even lower than the one of clusters. As a mark of success, several Desktop Grid platforms are daily used in production by large companies in the domains of pharmacology, petroleum, aerospace, etc. The origin of Desktop Grids came from the association of several key concepts: 1) cycle stealing, 2) computing over several administration domains and 3) the Master-Worker computing paradigm. Desktop Grids inherit the principle of aggregating inexpensive, often already in place, resources, from past research in cycle stealing. Roughly speaking, cycle stealing consists of using the CPU’s cycles of other computers. This concepts is particularly relevant when the target computers are idle. Mutka and al. demonstrated in 1987 that the CPU’s of workstations are mostly unused (M. W. Mutka & Livny, 1987), opening the opportunity for high demanding users to scavenge these cycles for their applications. Due to its high attractiveness, cycle stealing has been studied in many research projects like Condor (Litzkow, Livny, Mutka, 1988), Glunix (Ghormley, Petrou, Rodrigues, Vahdat, Anderson, 1998) and Mosix (Barak, Guday, 1993), to cite a few. In addition to the development of these computing environments, a lot of research has focused on theoretical aspects of cycle stealing (Bhatt, Chung, Leighton, Rosenberg, 1997). Early cycle stealing systems where bounded to the limits of a single administration domain. To harness more resources, techniques were proposed to cross the boundaries of administration domains. A first approach was proposed by Web Computing projects such as Jet (Pedroso, Silva, Silva, 1997), Charlotte (Baratloo, Karaul, Kedem, Wyckoff, 1996), Javeline (P. Cappello et al., 1997), Bayanihan (Sarmenta & Hirano, 1999), SuperWeb (Alexandrov, Ibel, Schauser, Scheiman, 1997), ParaWeb (Brecht, Sandhu, Shan, Talbot, 1996) and PopCorn (Camiel, London, Nisan, Regev, 1997). These projects have emerged with Java, taking benefit of the virtual machine properties: high portability across heterogeneous hardware and OS, large diffusion of virtual machine in Web browsers and a strong security model associated with bytecode execution. Performance and functionality limitations are some of the fundamental
32
Desktop Grids
motivations of the second generation of Global Computing systems like COSM4, BOINC (Anderson, 2004) and XtremWeb (Fedak, Germain, Néri, Cappello, 2001). These systems use some firewall and NAT traversing protocols to transport the required communications. The Master-Worker paradigm is the third enabling concept of Desktop Grids. The concept of MasterWorker programming is quite old (Mattson, Sanders, Massingill, 2004), but its application to large scale computing over many distributed resources has emerged few years before 2000 (Sarmenta & Hirano, 1999). The Master-Worker programming approach essentially allows the implementing of non trivial (bag of tasks) parallel applications on loosely coupled computing resources. Because it can be combined with simple fault detection and tolerance mechanisms, it fits extremely well with the Desktop Grid platforms that are very dynamic by essence.
Main Principles Desktop Grids have emerged while the community was considering clustering and hierarchical designs as good performance-cost tread-offs. However several parameters distinguish Desktop Grids from clusters: scale, communication, heterogeneity and volatility. Moreover, Desktop Grids share with Grid a common objective: to extend the size and accessibility of a computing infrastructure beyond the limit of a single administration domain. In (Foster & Iamnitchi, 2003), the authors present the similarities and differences between Grids and Desktop Grids. Two important distinguishing parameters are the user community (professional or not) and the resource ownership (who own the resources and who is using them). From the system architecture perspective, we consider two main differences: the system scale and the lack of control of the participating resources. The notion of Large Scale is linked to a set of features that has to be taken into account. An example is the system dynamicity caused by node volatility: in Internet Computing Plaforms (also called Desktop Grids), a non predictable number of nodes may leave the system at any time. Some researches even consider that they may quit the system without any prior mention and reconnect the system in the same way. The lack of control of the participating nodes has a direct consequence on nodes connectivity. Desktop Grid designers cannot assume that external administrator is able to intervene in the network setting of the nodes, especially their connection to Internet via NAT and Firewalls. This means that we have to deal with the in place infrastructure in terms of performance, heterogeneity, dynamicity and connectivity. Large scale and lack of control have many consequences, at least on the architecture of system components, the deployment methods, programming models, security (trust) and more generally on the theoretical properties achievable by the system. These characteristics established a new research context in distributed systems. From previous considerations, the Desktop Grid designers arrived to a set of properties that any Desktop Grid system should fulfill: resources connectivity across administrative boundaries, resilience to high resource volatility, job scheduling efficient for heterogeneous resources, standalone, self and automatically managed resource applications. Several extra properties have been considered and integrated in some Desktop Grids: resources security, results certification, etc. Figure 1 presents the simple architecture of basic Desktop Grids. A typical Desktop Grid consists in 3 components: clients that submit requests, servers that accept request and return results and a coordinator that schedules the client requests to the servers. Desktop Grids have applications in High Throughput Computing as well as in data access and communication. Thus, for a shake of simplicity, the requests and results presented in the figure can be either for computing or data operations. Clients may send requests with some specific requirements, such as CPU
33
Desktop Grids
Figure 1. General architecture of desktop Grids
architecture, OS version, the availability of some applications and libraries. Because only some servers may provide the required environment, the task of the coordinator is generally extended to realize the match making between clients requests and servers capabilities. Clients and servers are PCs belonging to different administrative domains. They are protected by firewall and may sit behind a NAT. By default, there is no possibility of direct communication between them. As a consequence, any Desktop Grid should implement some protocols to cross administrative domains boundaries. The communication between the components of the Desktop Grid concerns, data, job descriptions, job parameters and results but also application codes. If the application is not available on servers, it is transmitted by the client or the coordinator to the servers, prior to the execution. The coordinator can be implemented in various ways. The simple organization consists in a central node. This architecture can be extended to support the central node failure by using replicated nodes. Other designs consider using a distributed architecture where several nodes handle and manage the clients requests and server results. In addition to scheduling and matchmaking, the coordinator must implement fault detection and fault tolerance mechanisms because it is expected that some servers fail or quite the Desktop Grid (permanently or not) without prior notification. The lack of control of the servers implies that Desktop Grids rely on humans (In most cases, the owners of the PCs) for the installation of the server software on participating PCs. However Desktop Grid systems must not rely on PC owners for the managements and maintenance of the software. Thus the server software is designed to allow remote upgrade and remote management. The server software as well as all other Desktop Grid related software components are managed remotely by the Desktop Grid administrator.
CLASSIFICATION OF DESKTOP GRIDS In this section, we propose a classification of the Desktop Grids systems.
34
Desktop Grids
Figure 2. Overview of the OurGrid platform architecture
Local Desktop Grids Enterprise Desktop Grid consists of Desktop PC hosts within a LAN. LAN’s are often found within a corporation or University, and several companies such as Entropia and United Devices have specifically targeted these LAN’s as a platform for supporting Desktop Grid applications. Enterprise Desktop Grids are an attractive platform for large scale computation because the hosts usually have better connectivity with 100Mbps Ethernet for example and have relatively less volatility and heterogeneity than Desktop Grids that span the entire Internet. Nevertheless, compared to dedicated clusters, enterprise Desktop Grids are volatile and heterogeneous platforms, and so the main challenge is then to develop fault-tolerant, scalable, and efficient scheduling. Enterprises also provides commercial Desktop Grids. Their source code is most of the time unavailable and there is less documentation about their internal components. The server part may be available for use inside an enterprise. There are several industrial Desktop Grid platforms from Entropia (Chien et al., 2003) (ceased commercial operations in 2004), from United Device, Platform, Mesh Technologies.
Collaborative Desktop Grids Collaborative Desktop Grids consists of several Local Desktop Grids which agree to aggregate their resources for a common goal. The OurGrid project (Andrade, Cirne, Brasileiro, Roisenberg, 2003 ; Cirne et al., 2006) is a typical example of such systems. It proposes a mechanisms for laboratories to put together their local Desktop Grids. A mechanism allows the local resource managers to construct a P2P network (Figure 2). This solution is attractive because utilization of computing power by scientists is usually not constant. When scientists need an extra computing power, this setup allows them to access easily their friend universities resources. In exchange, when their resources are idle, it can be given or rented to others universities. This requires a cooperation of the local Desktop Grid systems, usually at the resource manager level, and mechanisms to schedule several applications. A similar approach has been proposed by the Condor team under the term “flock of condor” (Pruyne & Livny, 1996).
35
Desktop Grids
Internet Volunteer Desktop Grids For over a decade, the largest distributed computing platforms in the world have been Internet Volunteer Desktop Grids, (IVDG) which use the idle computing power and free storage of a large set of networked (and often shared) hosts to support large-scale applications. In this case of Grid, owners of resources are end-user Internet volunteer who provide their personal computer for free. IVDG are an extremely attractive platform because they offer huge computational power at relatively low cost. Currently, many projects, such as SETI@home (Anderson, Cobb, Korpela, Lebofsky, Werthimer, 2002), FOLDING@ home (Shirts & Pande, 2000), and EINSTEIN@home5, use TeraFlops of computing power of hundreds of thousands of desktop PC’s to execute large, high-throughput applications from a variety of scientific domains, including computational biology, astronomy, and physics.
Single-Application Internet Volunteer Desktop Grids. At the beginning of Internet Volunteer Desktop Grids, most of the largest projects were running only one application. Only data were automatically distributed, most of the time using a simple CGI script on a web server. Upgrading the application was requiring that volunteers manually download and install the application. In this section, we will describe some of these projects. The Great Internet Mersenne Prime Search (GIMPS)6 is one of the oldest computation using resources provided by volunteer Desktop Grid users. It’s started in 1996 and still running. The 44th known Mersenne prime have been found in september 2006. Each client connect to a central server (PrimeNet) to get some works. Resources are divided in 3 classes based on the processor model and gets different type of tasks. The program only use 8Mb of RAM, 10Mb of disk space and do very little communications with the servers (permanent connection is not required). The program checkpoints every half hour. Since 1997, Distributed.net7 tries to solve cryptographic challenges. RC5 and several DES challenges have been solved. The first version of SETI@Home has been released in may 1999. There was already 400,000 preregistered volunteers. 200,000 clients registered the first week. Between July 2001 and July 2002, the platform computed workunits at an average rate of 27.36 TeraFLOPS. The programs is doing some treatments on a signal recorded by a radio-telescope and then search for particular artificially made signal in it. The original record is split in workunit both by time (107s long) and by frequency (10KHz) The Electric Sheep8 (Draves, 2005) screen-saver “realizes the collective dream of sleeping computers”. It harnesses the power of idle computers (because they are running the screen-saver) to render, using a genetic algorithm, the fractal animation displayed by itself. The computation uses the volunteers to decide which animation is beautiful and should be improved. This system consists only of one application but, as the project website claims, about 30,000 unique IP addresses contact the server each day and 2Tb are transfered. At article writing time, the unique centralized server was the bottleneck of this system.
XtremWeb. XtremWeb (Fedak et al., 2001; Cappello et al., 2004) is an open source research project at LRI and LAL that belongs to light weight Grid systems. It is primary designed in order to explore scientific issues about Desktop Grid, Global Computing and Peer to Peer distributed systems but have been also used in real computations, especially in physics. First version was released in 2001.
36
Desktop Grids
Figure 3. Overview of the XtremWeb platform architecture
The architecture (Figure 3) is similar to most well known platforms. It is a three-tier architecture with clients, servers and workers. Several instances of those components might be used at the same time. Clients allows platform’s users to interact with the platform by submitting stand-alone jobs, retrieving results and managing the platform. Workers are responsible for executing jobs. The server is a coordination service that connects clients and workers. The server accepts tasks from clients, distributes them to workers according to the scheduling policy, provides applications for running them and supervises the execution by detecting worker crash or disconnection. If needed tasks are restarted on other available workers. At the end, it retrieves and stores results before clients download them. Clients and Workers are initiators of all connections to the server which have for consequence that only the server needs to be accessible from behind firewalls. Multiples protocols are supported and can be used depending on the type of workload. Communications may also be secured both by encryption and authentication. Since its first version, XtremWeb has been deployed over networks of common Desktop PCs providing an efficient and cost effective solution for a wide range of application domains: bioinformatics, molecular synthesis, high energy physics, numerical analysis and many more. At the same time, there have been many researches around Xtremweb: XtremWeb-CH9 (Abdennadher & Boesch, 2006) funded by the University of Applied Sciences in Geneva, is an enrichment of XtremWeb in order to better match P2P concepts. Communications are distributed, i.e. direct communications between workers are possible. It provides a distributed scheduler that takes into account the heterogeneity and volatility of workers. There is an automatic detection of the optimal granularity according to the number of available workers and scheduling tasks. There is also a monitoring tool for visualizing the executions of the applications.
BOINC All these mono-application projects share many common components. So, there was a need for a generic platform that would provide all these components for an easy integration and deployment of these
37
Desktop Grids
Figure 4. Overview of the BOINC platform architecture
projects. Only the part that really does the computation need to be changed for each project. The Berkeley Open Infrastructure for Network Computing (BOINC) (Anderson, 2004) is the largest volunteer computing platform. More than 900,000 users from nearly all countries participate with more than 1,300,000 computers. More than 40 projects, not including private projects, are available including the popular SETI@Home project. Projects usually last several month mainly because of the time needed to attract volunteers and set up a users community. Each client (computing node) is manually attached by the user to one or more projects (servers). Each project runs a central server (Figure 4) and most of the scheduling is done by clients. Projects have the ability to run several a small number of different applications which can be updated (jobs have to be very homogeneous). The BOINC server is composed of several daemons which execute the management tasks: first, workunits are produced by a generator. Then, the transitioner, the daemon that will take care of the different states of the workunit life cycle, will replicate (redundancy) the workunit in several results (instances of workunits). Each result will be executed on a different client. Then, back to the server, each result will be checked by the validator before being stored in the project science database by the assimilator. All communications are done using cgi programs on the project server, so, only port 80 and client to server connections are needed. Each user is rewarded with credits, a virtual money, for the count of cycles used on its computer. The client maintains a cache of results to be executed between connections to the Internet. The scheduler tries to enforce many constraints: First, the user may choose to run the applications according to its activity (screen-saver), working hours, resources available. Second, the user assigns a resource share ratio to the projects. Third, sometimes, some projects may run out of work to distribute.
38
Desktop Grids
Some others projects were inspired by the BOINC platform. SLINC10 (Baldassari, Finkel, & Toth, 2006) addresses the main limitations of BOINC by simplifying the project creation process. This software is also operating system independent as it runs on the Java platform. It is also database independent (use Hibernate) while BOINC runs only with Mysql. All communications between components are done with XML-RPC and for simplifying the architecture, they have removed the validator component. User’s applications are also programming language independent, but only Java and C++ available for now. Two versions of the same application, the first one written in Java, the second one written in C++ have almost the same performance. Some BOINC issues have not been fixed here, such as the time needed to have all the volunteers register their resources. The POPCORN (Nisan, London, Regev, Camiel, 1998) is a platform for global distributed computing over the Internet. It has been available from mid 1997 until mid 1998. Today, only the papers and documentation are still available. This platform runs on the Java platform and tasks are executed on workers as “computelets”, a system similar to usual Java applets. Computelets need only to be instanciated for a task to be distributed. Error and verification process is left to the application level. The platform provides a debugging tool that shows the tree of spawned computelets (for debugging concurrency issues). There is also a market system that enable users to sell their CPU time. The currency works almost the same as BOINC credits. Some applications have been tested on the platform: brute force breaking, genetic algorithm,... At the implementation level, they had some issues with Java immaturity (in 1997-1998). Bayanihan (Sarmenta & Hirano, 1999) is another platform for volunteer computing over the Internet. It is written in Java and uses Hord, a package similar to Sun’s RMI for communications. Many clients (applet started from a web browser or command line applications) connect to one or more servers. Korea@Home (Jung, 2005) is a Korean volunteer computing platform. Work management is centralized on one server but since version 2, there is a P2P mechanism that allows direct communication between computing nodes (agents). This platform harnesses more than 36,000 agents, about 300 of them are available at the same time.
EVOLUTION OF MIDDLEWARE ARCHITECTURE Job Management The functionality required for job management includes job submission, resource discovery, resource selection and scheduling, and resource binding. With respect to job submission, most systems, like XtremWeb or Entropia, have a interface similar to batch systems, such as PBS, where a job’s executable and inputs are specified. Recently, there have been efforts to provide higher-level programming abstractions, such as Map-Reduce (Dean & Ghemawat, 2004). After a job is submitted to the system, the job management system must identify a set of available resources. Resource discovery is the process of identifying which resources are currently available and is challenging given the dynamicity and large-scale of systems. There have been both centralized and distributed approaches. The classic method is via matchmaking (Raman, Livny, Solomon, 1998) where application requirements are paired with compatible resource requirements via ClassAds. A number of works have addressed the scalability and fault-tolerance issue of this type of centralized matchmaking system.
39
Desktop Grids
Several distributed approaches have been proposed. The challenges of building a distributed resource discovery system are the overheads of distributing queries, guaranteeing that queries can be satisfied, being able to support a range of application constraints specified through queries, and being able to handle dynamic loads on nodes. In (Zhou & Lo, 2006), the authors propose distributed resource discovery using a distributed hash table (DHT) in the context of a P2P system. This was one of the first P2P resource discovery mechanisms ever proposed. However, one the characteristics of resources can be heavily skewed such that the query load is heavily imbalanced. In (Iamnitchi, Foster, Nurmi, 2002), the authors propose a P2P approach where the overheads of a query are limited with a time-to-live (TTL). The drawback of this approach is that there is no guarantee that a resource that meets the constraints of the application will be found. In (Kim et al., 2006), the authors proposed a rendezvous-node tree (RNT) where load is balanced using random application assignment. The RNT deals with load dynamics by conducting a random-walk (of limited length) after the mapping. In (Lee, Ren, Eigenmann, 2008), the authors use a system where information is summarized hierarchically, and a bloom filter is used to reduce the overheads for storage and maintenance. After a set of suitable resources have been determined, the management system must then selection a subset of the resources and determine how to schedule tasks among the resources. We discuss this issue in-depth in next section. One resources have been selected and a schedule has been determined, the tasks must then be deployed across resources, i.e., bound. In systems such the Condor Matchmaker, binding occurs last in a separate step between the consumer and provider (without the matchmaker as the middle-man) to allow for the detection of any change in state. If change in state occurs (for example, the resource is no longer available), then the renegotiation of selected resources can occur.
Resource Scheduling At the application and resource management level, most research assumes that a centralized scheduler maintains a queue of tasks to be scheduled, and a ready queue of available workers. As workers become available, they notify the server, and the scheduler on the server places the corresponding task requests of workers in the ready queue. During resource selection, the scheduler examines the ready queue to determine the possible choices for task assignment. Because the hosts are volatile and heterogeneous, the size of the host ready queue changes dramatically during application execution as workers are assigned tasks (and thus removed from the ready queue), and as workers of different speeds and availability complete tasks and notify the server. The host ready queue is usually only a small subset of all the workers, since workers only notify the server when they are available for task execution. At the Worker level, most research assumes that the worker running on each host periodically sends a heartbeat to the server that indicates the state of the task. In the XtremWeb system (Fedak et al., 2001), a worker sends a heartbeat every minute to indicate whether the task is running or has failed. With respect to the recovery from failures, some works assume local checkpointing abilities. However, remote checkpointing is still work in progress in real Internet-wide systems such as BOINC (Anderson, 2004) and XtremWeb (Fedak et al., 2001). Also, most works do not assume the server can cancel a task once it has been scheduled on a worker. The reason for this is that resource access is limited, as firewalls are usually configured to block all incoming connections precluding incoming RPC’s and to allow only outgoing connections (often on a restricted set of ports like port 80). As such, the heuristics cannot preempt a task once it has been as-
40
Desktop Grids
signed, and workers must make the initiative to request tasks from the server. This platform model deviates significantly from traditional grid scheduling models (Berman, Wolski, Figueira, Schopf, Shao, 1996 ; Casanova, Legrand, Zagorodnov, Berman, 2000 ; Casanova, Obertelli, Berman, Wolski, 2000 ; Foster & Kesselman, 1999). The pull nature of work distribution and random behavior of resources in desktop grids places several limitations on scheduling operations. First, it makes advance planning with sophisticated Gantt charts difficult as resources may not be available for task execution at the scheduled time slot. Second, as task requests are typically handled in a centralized fashion and a (web) server can handle a maximum of a few hundred connections, the choice of resources available is always a small subset of the whole. Nevertheless, we focus on scheduling solutions applicable in current centralized systems below. The majority of application models in desktop grid scheduling have focused on jobs requiring either high-throughput (Sonnek, Nathan, Chandra, Weissman, 2006) or low latency (Heien, Fujimoto, Hagihara, 2008 ; Kondo, Chien, 2004). These jobs are typically compute-intensive. There are four complementary strategies for scheduling in desktop grid environments, namely resource selection, resource prioritization, task replication, and host availability prediction. In practice, these strategies are often combined in heuristics. With respect to resource selection, hosts can be prioritized according to various static or dynamic criteria. Surprisingly, simple criteria such as clock rates has been shown to be effective with real-world traces (Kondo, Chien, 2004). Other studies (Kondo, Chien, Casanova, 2007 ; Sonnek et al., 2006) have used probabilistic techniques based on a hosts history of unavailability to distinguish more stables hosts from others. With respect to resource exclusion, hosts can be excluded using various criteria, as often slow hosts (either due to failures, slow clock rates, or other host load) are the bottlenecks in the computation. Thus, excluding them from the entire resource pool can improve performance dramatically. With respect to task replication, schedulers often replicate a fixed number of times. The authors in the studies (Kondo et al., 2007) and (Sonnek et al., 2006) investigated the use of probabilistic methods for varying the level of replication according to a host’s volatility. With respect to host availability prediction, recently the authors in (Andrzejak, Domingues, Silva, 2006) have shown that simple prediction methods (in particular a naive bayes classifier) can allow one to give guarantees on host availability. In particular, in that study, the authors show how to predict that N hosts will be available for T time.
Volatility Tolerance There are several issues with volatility concerning detection and resolution. With respect to detection, systems such as XtremWeb (Fedak et al., 2001) and Entropia (Chien et al., 2003) use heartbeats. In BOINC, where a centralized (web) server can only handle a few hundred simultaneously, the use of heartbeats with millions of resources is not an option. Moreover, heartbeats can’t be used when BOINC operate without network connection. Instead BOINC uses job deadlines as a indication of whether the job as permanently failed or not. When a failure has been detected, one can resolve the failure in a number of ways. Task checkpointing is one means of dealing with task failures since the task state can be stored periodically either on the local disk or on a remote checkpointing server; in the event that a failure occurs, the application can be restarted from the last checkpoint. In combination with checkpointing, process migration can be
41
Desktop Grids
used to deal with CPU unavailability or when a “better” host becomes available by moving the process to another machine. The authors in (Araujo, Domingues, Kondo, Silva, 2008 ; Domingues, Araujo, Silva, 2006) develop a distributed checkpoint system where checkpoints are stored in peers in a P2P fashion using a DHT, or using a clique. Thus, when a failure occurs, a checkpoint could potentially be used to restart the computation on another node in scalable way. Another common solution for masking failures is replication. The authors in (Ghare & Leutenegger, 2004 ; Kondo et al., 2007 ; Sonnek et al., 2006) use probabilistic models to analyze various replication issues. The platform model used in (Ghare & Leutenegger, 2004) assumes that the resources are shared, task preemption is disallowed, and checkpointing is not supported. The application models was based on tightly-coupled applications, while the other was based on loosely-coupled application, which consisted of task parallel components before each barrier synchronization. The authors then assume that the probability of task completion follows a geometric distribution. The work in (Leutenegger & Sun, 1993) examines analytically the costs of executing task parallel applications in desktop grid environments. The model assumes that after a machine is unavailable for some fixed number of time units, at least one unit of work can be completed. Thus, the estimates for execution time are lower bounds. The assumption is restrictive, especially since the size of an availability intervals can be correlated in time (Mutka & Livny, 1991); that is, a short availability interval (which would likely cause task failure) will most likely be followed by another short availability interval. In terms of proactively avoiding failures, the authors in (Andrzejak, Kondo, Anderson, 2008) use prediction methods for avoiding resources likely to fail. They show the existence of long stretches of availability of certain Internet hosts and that such patterns can be modeled efficiently with basic classification algorithms. Simple and computationally cheap metrics are reliable indicators of predictability, and resources can be divided into high and low predictability groups based on such indicators. So, they show that a deployment of enterprise services in a pool of volatile resources is possible and incurs reasonable overheads.
Data Management Despite the attractiveness of Desktop Grids, little work has been done to support data-intensive applications in this context of massively distributed, volatile, heterogeneous, and network-limited resources. Most Desktop Grid systems, like BOINC (Anderson, 2004), XtremWeb (Fedak et al., 2001), Condor (Litzkow et al., 1988) and OurGrid (Andrade et al., 2003) rely on a centralized architecture for indexing and distributing the data, and thus potentially face issues with scalability and fault tolerance. Thus, data management is still a challenging issue. Parameter-sweep applications composed of a large set of independent tasks sharing large data are the first class of applications which has driven a lot of effort in the area of data distribution. Authors in (Wei, Fedak, Cappello, 2005) have shown that using a collaborative data distribution protocol BitTorrent over FTP can improve execution time of parameter sweep applications. In contrast, it has also been observed that the BitTorrent protocol suffers a higher overhead compared to FTP when transferring small files. Thus, one must be allowed to select the correct distribution protocol according to the size of the file and level of “sharability” of data among the task inputs. Recently, a similar approach has been followed in (Costa, Silva, Fedak, Kelley, 2008), where the BitTorrent protocol has been integrated within the BOINC platform.
42
Desktop Grids
This works confirm that the basic blocks for building Data Management components can be found in P2P systems. Recently, a subsystem dedicated to data management for Desktop Grid, named BitDew, has been proposed in (Fedak, He, Cappello, 2008). It could be easily integrated into systems like BOINC, OurGrid or XtremWeb. It offers programmers (or an automated agent that works on behalf of the user) a simple API for creating, accessing, storing and moving data with ease, even on highly dynamic and volatile environments. Researchers of DHT’s (Distributed Hash Tables) (Stoica, Morris, Karger, Kaashoek, Balakrishnan, 2001 ; Maymounkov & Mazières, 2002 ; Rowstron & Druschel, 2001) and collaborative data distribution (Cohen, 2003 ; Gkantsidis & Rodriguez, 2005 ; Fernandess & Malkhi, 2006), storage over volatile resources (Bolosky, Douceur, Ely, Theimer, 2000 ; Butt, Johnson, Zheng, Hu, 2004 ; Vazhkudai, Ma, Strickland, Tammineedi, Scott, 2005) and wide-area network storage (Bassi et al., 2002 ; Rhea et al., 2003) offer various tools that could be of interest for Data Grids. To build Data Grids from and to utilize them effectively, one needs to bring together these components into a comprehensive framework. BitDew suits this purpose by providing an environment for data management and distribution in Desktop Grids. Large data movement across wide-area networks can be costly in terms of performance because bandwidth across the Internet is often limited, variable and unpredictable. Caching data on the local storage of the Desktop PC (Iamnitchi, Doraimani, Garzoglio, 2006 ; Otoo, Rotem, Romosan, 2004 ; Vazhkudai et al., 2005) with adequate scheduling strategies (Santos-Neto, Cirne, Brasileiro, Lima, 2004 ; Wei et al., 2005) to minimize data transfers can improve overall application execution performance. Long-running applications are challenging due to the volatility of executing nodes. To achieve application execution, it requires local or remote checkpoints to avoid losing the intermediate computational state when a failure occurs. In the context of Desktop Grid, these applications have to cope with replication and sabotage. An idea proposed in (Kondo, Araujo, et al., 2006) is to compute a signature of checkpoint images and use signature comparison to eliminate diverging execution. Thus, indexing data with their checksum as commonly done by DHT and P2P software permits basic sabotage tolerance even without retrieving the data. BitDew leverages the use of metadata, a technique widely used in Data Grid (Jin, Xiong, Wu, Zou, 2006), but in more directive style. It defines 5 different types of metadata: i) replication indicates how many occurrences of data should be available at the same time in the system, ii) fault tolerance controls the resilience of data in presence of machine crash, iii) lifetime is a duration, absolute or relative to the existence of other data, which indicates when a datum is obsolete, iv) affinity drives movement of data according to dependency rules, v) transfer protocol gives the runtime environment hints about the file transfer protocol appropriate to distribute the data. Programmers tag each data with these simple attributes, and simply let the BitDew runtime environment manage operations of data creation, deletion, movement, replication, as well as fault tolerance.
Security Model In this section we review the security model of several Desktop Grid system. The BOINC (Anderson, 2004) middleware is a popular Volunteer Computing System which permits to aggregate huge computing power from thousands of Internet users. A key points is the asymmetry of its security model: there are few projects well identified and which belongs to established institutions (by example, University of Berkeley for the SETI@Home project) while volunteers are numerous and anonymous. Of course the notion of users exists in BOINC, because volunteers needs to receive a re-
43
Desktop Grids
ward from their contribution. However, the definition of a users is close to the one of avatar: it allows users to participate to forum and receives credits according to the computing time and power given to the project. Despite anonymity, the security model is based on trust. Volunteers trust the project they are contributing to. Security mechanism is simple and based on asymmetric cryptography. Security model aims at enforcing the trust between volunteers and the project they participate in. At installation time, the owners of a project produce a pair of public/private keys and stores those keys in a safe place, typically, as recommended on the BOINC web site in a machine isolated from the network. When volunteers contribute for the first time to the project, they obtain the public key of the project. Project owners have to digitally sign the application files of the project, so that volunteers can verify that the binary codes downloaded by the BOINC client really belongs to the project. This mechanism ensures that, if a pirate get access to one of the BOINC server, he would not be able to upload malicious code to hundreds of thousands users. If volunteers trust the projects, the reverse is not true. To protect against malicious users, BOINC implements a result certification mechanism (Sarmenta, 2002), based on redundant computation. BOINC gives the ability to project administrator to write their own custom results certifying code according to their application. XtremWeb is an Internet Desktop Grid middleware which also permits public resources computing. It differs from BOINC by the ability given to every participants to submit new applications and tasks in the system. XtremWeb is a P2P system in the sense that every participant can provide computing resources but also utilize others participants’ computing resources. XtremWeb is organized as a three-tiers architecture where clients consumes resources, worker provides resources and coordinator is a central agent which manages the system by performing the scheduling and fault-tolerance tasks. Even if BOINC defines users in its implementation, they are anonymous and are only used to facilitate the platform management They can’t be trusted, only project owners can be trusted. In contrast with BOINC, because everyone can submit application, there cannot be any form of trust between users, applications, results and even the coordinator itself. Thus XtremWeb security model is based on autonomous mechanisms which aims at protecting each component of the platform from the others elements. For instance, to protect volunteers’ computer from malicious code, a sandbox mechanism is used to isolate and monitor the running application, and prevent it to damage volunteers system. Public/ private keys mechanism are also used to authenticate the coordinator to prevent results to be uploaded to another coordinator. The XGRID system, proposed by Apple is a Desktop Grid designed to run on a local network environment. XGrid features ease of use and ease of deployment. To work, the Xgrid system needs a Xgrid server, which can be configured with or without password. If the server run without password, then every user in the local environment can submit jobs and application, else only those who can authenticate to the servers are granted this authorization. Computing nodes, in the Xgrid system can accept jobs or no, this property is set on the computing nodes itself. Thus there is no real distinction between users and there’s no possibility for a user or a machine to accept or refuse other users’ application or work. While this solution is acceptable when used within a single organization (lab or small company), this solution would not scale to a large Grid setup which typically aims at several institutions to cooperate.
44
Desktop Grids
Figure 5. Bridging service Grid and desktop Grid, the superworker approach vs. the gliding-in approach
Bridging Service Grids and Desktop Grids There exists 2 main approaches to bridge Service Grids and Desktop Grids (see Fig. 5). In this section we present the principles of these two approaches and discuss them according to security perspective.
The Superworker Approach Since the superworker is a centralized agent this solution has several drawbacks: i) the superworker can become a bottleneck when the number of computing resources increases, ii) the round trip for a work unit is increased because it has to be marshalled/unmarshalled by the superworker, iii) it introduces a single point of failure in the system, which has low fault-tolerance. On the other hand, this centralized solution provides better security properties, concerning the integration with the Grid. First the superworker does not require modification of the infrastructure, it can be ran under any user identity as long as the user has the right to submit jobs on Grid. Next, as works are wrapped by the by the superworker, they are run under the user identity, which conforms with the regular security usage, in contrast with the approach described in the following paragraph. A first solution proposed used by the Lattice (Myers, Bazinet, Cummings, 2008) project and the SZTAKI Desktop Grid (Balaton et al., 2007) is to build a superworker which enables several Grid or cluster resources to compute to a Desktop Grid. The superworker is a bridge implemented as a daemon between the Desktop Grid server and the Service Grid resources. From the Desktop Grid server point of view, the Grid or cluster appears as one single resources with large computing capabilities. The superworker continuously fetches tasks or work units from the Desktop Grid server, wraps and submits the tasks accordingly to the local Grid or cluster resources manager. When the computations are finished on the SG computing nodes, the superworker send back the results to the Desktop Grid server. Thus,
45
Desktop Grids
the superworker by itself is a scheduler which needs to continuously scan the queues of the computing resources and watch for available resources to launch jobs.
The Gliding-In Approach The Gliding-in approach to cluster resources spread in different Condor pool using the Global Computing system (XtremWeb) was first introduced in (Lodygensky et al., 2003). The main principle consists in wrapping the XtremWeb worker as regular condor task and submit this task to the Condor pool. Once the worker is executed on a Condor resource, the worker pulls jobs from the Desktop Grid server, executes the XtremWeb task and return the result to the XtremWeb server. As a consequence, the Condor resources communicates directly to the XtremWeb server. Similar mechanisms are now commonly employed in Grid Computing (Thain & Livny, 2004). For example Dirac (Tsaregorodtsev, Garonne, Stokes-Rees, 2004) uses a combination of push/pull mechanism to execute jobs on several Grid clusters. The generic approach on the Grid is called a pilot job. Instead of submitting jobs directly to the Grids gatekeeper, this system submits so-called pilot jobs. When executed, the pilot job fetches jobs from an external job scheduler. The gliding-in or pilot job approach has several advantages. While simple, this mechanism efficiently balance the load between heterogeneous computing sites. It benefits from the fault tolerance provided by the Desktop Grid server: if Grid nodes fail then jobs get rescheduled to the next available resources. Finally, as the performance study of the Falskon (Raicu, Zhao, Dumitrescu, Foster, Wilde, 2007) system shows, it gives better performances because series of jobs does not have to go throught the gatekeeper queues which is generally characterized by long waiting time, and communications are direct between the CE and the Desktop Grid server without intermediate agent such as the superworker. From the security point of view, this approach breaks the Grid security rules because jobs owner may be different than pilot job owners. This is a well known issue of pilot jobs and new solution such as gLExec (Sfiligoi et al., 2007) are proposed to circumvent this security hole.
Result Certification Result certification in desktop grids is essential for several reasons. First, malicious users can report erroneous results. Second, hosts can unintentionally report erroneous results because of viruses that corrupt the system or hardware problems (for example overheating of the CPU). Third, differences in system or hardware configuration can result in different computational results. We discuss three of the most common state-of-the-art methods (Sarmenta, 2002 ; Zhao & Lo, 2001; Taufer, Anderson, Cicotti, 2005) for result certification namely spot-checking, majority voting, and credibility-based techniques, and emphasize the issues related to each method. The majority voting method detects erroneous results by sending identical workunits to multiple workers. After the results are retrieved, the result that appears most often is assumed to be correct. In (Sarmenta, 2002), the author determines the amount of redundancy for majority voting needed to achieve a bound on the frequency of voting errors given the probability that a worker returns a erroneous result. Let the error rate be the probability that a worker is erroneous and returns an erroneous result unit, and let be the percentage of final results (after voting) that are incorrect. Let m be the number of identical results out of 2m−1 required before a vote is considered complete and a result is decided upon. Then the probability of an incorrect result being accepted after a majority
46
Desktop Grids
vote is given by: ö æ 2m -1 ç2m - 1÷ j ÷÷j (1 - j)2m -1- j majv (j, m ) = å j =m çç ÷÷ j çè ø
(1)
The redundancy of majority voting is m 1-f . The main issues for majority voting are the following. First, the error bound assumes that error rates are not correlated among hosts. Second, majority voting is most effective when error rates are relatively low (≤1%); otherwise the required redundancy could be too high. A more efficient method for error detection is spot-checking, whereby a workunit with a known correct result is distributed at random to workers. The workers’ results are then compared to the previously computed and verified result. Any discrepancies cause the corresponding worker to be blacklisted, i.e., any past or future results returned from the erroneous host are discarded (perhaps unknowingly to the host). Erroneous workunit computation was modelled as a Bernoulli process (Sarmenta, 2002) to determine the error rate of spot-checking given the portion of work contributed by the host, and the rate at which incorrect results are returned. The model uses a work pool that is divided into equally sized batches. Allowing the model to exclude coordinated attacks, let q be the frequency of spot-checking, let n be the amount of work contributed by the erroneous worker, let f be the fraction of hosts that commit at least 1 error, and let s be the error rate per erroneous host. (1-qs)n is the probability that an erroneous host is not discovered after processing n workunits. The rate which spot-checking with blacklisting will fail to catch bad results is given by: scbl (q, n, f , s ) =
sf (1 - qs )n (1 - f ) + f (1 - qs )n
(2)
The amount of redundancy of spot-checking is given by 1 1-q . There are several critical issues related to spot-checking with blacklisting. First, it assumes that blacklisting will effectively remove erroneous hosts, in spite of the possibility of hosts registering with new identities or high host churn as shown by (Anderson & Fedak, 2006). Without blacklisting, the upper bound on the error rate is much higher and does not decrease inversely with n. Second, spot-checking is effective only if error rates are consistent over time. Third, spot-checking is most
47
Desktop Grids
effective when error rates are high (>1%); otherwise, the number of workunits to be computed per worker n must be extremely high. To address the potential weaknesses of majority voting and spot-checking, credibility-based systems were proposed (Sarmenta, 2002), which use the conditional probabilities of errors given the history of host result correctness. The idea is based on the assumption that hosts that have computed many results with relatively few errors have a higher probability of errorless computation than hosts with a history of returning erroneous results. Workunits are assigned to hosts such that more attention is given to the workunits distributed to higher risk hosts. To determine the credibility of each host, any error detection method such as majority voting, spotchecking, or various combinations of the two can be used. The credibilities are then used to compute the conditional probability of a result’s correctness.
RESEARCH AND ExPLORATION TOOLS Platforms Observations Prior to improve algorithms of existing platforms and simulate them, observing existing software real behavior on Internet is necessary. First, in (Kondo, Taufer, Brooks, Casanova, Chien, 2004 ; Kondo, Fedak, Cappello, Chien, Casanova, 2006) hundreds of desktop PC have been measured and characterized at the University of California at San Diego and the University of Paris-Sud. In (Anderson & Fedak, 2006), the authors measured aggregate statistics gathered through BOINC. A limitation of this work is that the measurements do not describe the temporal structure of availability of individual resources Recently, the XtremLab11 (Malécot, Kondo, Fedak, 2006) project, running on BOINC, have collected over 15 months of traces from 15,000 hosts. It runs an active measurement software that give the exact amount of computing power earned by the project by time for each node. After minimal treatment, they are used by simulators.
DG Simulation: SimBOINC There are several challenges for desktop grid simulation. First, one needs ways for abstracting failures and handling them. In simulation toolkits, one needs a way to specify the type of failure (permanent or transient) and how the system reacts to the failures (for example, restart after the system becomes available again). Simulators, such as SimGrid, are beginning to use exception handling for cleanly dealing with failures. Second, one needs to be able to deal with scaling issues. In some respects, building a trace-driven simulator using 50,000 resources is trivial when resources are not shared and they are interconnected with trivial network models. However, when resources are shared by a number of competing entities, issues of scale arise because one must recompute the allocation of the resource for each entity whenever the resource state changes. Third, as desktop grids and volunteer computing systems are invariably distributed over wide-area networks, one needs accurate network models that scale to hundreds and thousands of resources. The open issue is to get the speed of flow-based network models and at the same time the accuracy of packet-level simulation. Below we describe one recent approach for desktop grid simulation.
48
Desktop Grids
SimBOINC is a simulator for heterogeneous and volatile desktop grids and volunteer computing systems. The goal of this project is to provide a simulator by which to test new scheduling strategies in BOINC, and other desktop and volunteer systems, in general. SimBOINC is based on the SimGrid simulation toolkit for simulating distributed and parallel systems, and uses SimGrid (Casanova, Legrand, Quinson) to simulate BOINC (in particular, the client CPU scheduler, and eventually the work fetch policy) by implementing a number of required functionalities.
Simulator Overview. SimBOINC simulates a client-server platform where multiple clients request work from a central server. In particular, we have implemented a client class that is based on the BOINC client, and uses (almost exactly) the client’s CPU scheduler source code. The characteristics of client (for example, speed, project resource shares, and availability), of the workload (for example, the projects, the size of each task, and checkpoint frequency), and of the network connecting the client and server (for example, bandwidth and latency) can all be specified as simulation inputs. With those inputs, the simulator will execute and produce an output file that gives the values for a number of scheduler performance metrics, such as effective resource shares, and task deadline misses. The current simulator can simulate a single client that downloads workunits from multiple projects and use its CPU scheduler to decide when to schedule each workunit. The server in SimBOINC is different from the typical BOINC server in that there is one server for multiple projects, and so requests for work from multiple projects are channeled to a single server. The server consists of a request_handler that basically uses work_req_seconds and project_id parameters sent in the scheduler_request to determine the amount of work from a specific project to send to a client. We understand that for testing new work-fetch policies and CPU schedulers, only a single client that work downloads for multiple projects is needed. But we wanted SimBOINC to be a general purpose volunteer computing simulator that could simulate new uses of BOINC by different kinds of applications. For example, people should be able to use SimBOINC to simulate the scheduling of low-latency jobs or for simulating large peer-to-peer file distribution; in both these cases, simulating multiple clients would be essential.
Execution. SimBOINC expects the following inputs in the form of xml files: • • • • •
Platform file: This specifies the hosts in the platform and the network connecting the hosts. Host availability trace files: These are to be specified within the platform file. Workload file: This specifies the jobs, i.e., projects, to be executed on the clients. Client states file: This specifies the configuration of the BOINC Clients simulator file: This specifies the configuration of the specific simulator execution.
The platform file is where one constructs the computing and network resources on which the BOINC client and server run. In particular, SimBOINC expects a set of CPU resources, and a set of network links that connect those resources. For each resource, one can specify set of attributes. For
49
Desktop Grids
example, with CPU resources, one can specify the power, and corresponding availability trace files. For network resources, one can specify their bandwidth and latency. The workload file specifies the projects to be executed over the BOINC platform. In particular, it specifies for each project, the name, total number of tasks to execute, the task size in terms of computation, the task size in terms of communication, the checkpoint frequency for each task, and the delay_bound, and rsc_fpops_est BOINC task attributes.
Client States File. The client states input file is based on the client states format exported by the BOINC client to store persistent state. The idea is that the client states files could be collected and assembled to produce a client_states input file to SimBOINC, which would allow the simulation of BOINC clients using realistic settings.
Simulation File This simulation input file specifies the type of simulation to be conducted (e.g. BOINC), the maximum time for simulation after which the simulation will be terminated, and the output file name.
Using Availability Traces In SimGrid, the availability of network and CPU resources can be specified through traces. For CPU resources, one specifies a cpu availability file that denotes the availability of the cpu as a percentage over time. Also, for the cpu, one specifies a failure file that indicates when the cpu fails. A cpu is considered to fail when it is not available anymore for computation. In SimGrid, a CPU failure causes all processing running on that CPU to terminate. In BOINC, at least three things can cause an executing task to fail. First, the task could be preempted by the BOINC client because of the client scheduling policy. Second, the task could be preempted by the BOINC client because of user activity according to the user’s preferences. Third, the host could fail (for example due to a machine crash or shutdown). In SimBOINC, the failures of a host specified in the CPU trace files represent the failure resulting from the latter two causes. That is, when a cpu fails as specified in the traces, all processes on the cpu will terminate. However, their state is maintained and persists through the failure so that when the host becomes available again, the processes will be restarted in the same state. That is, the tasks that had been executing before the failure are restarted from the last checkpoint after the failure, and the client state data structure is the same as before the failure.
Logging SimBOINC uses the logging facility called XBT provided by SimGrid, which is similar in spirit to log4j (and in turn, log4cxx, and etc.) It allows for runtime configuration of messages output and the level of detail. However, it does yet support appenders. We chose to use XBT instead the BOINC’s message logger because XBT it integrated with SimGrid, and as such can show more informative messages by default (like the name of the process, the simulation time, and etc).
50
Desktop Grids
Simulator Output and Performance Metrics. The simulator output file must be specified in the simulation input file. The simulator then outputs the following metrics to that file in xml: for each client for each project that the client participates in total number of tasks completed resource share and effective resource shared calculated by the using the CPU time for each completed task compared to the total number and percentage of missed report deadlines for completed tasks number and percentage of report deadlines met for completed tasks. Also, for each CPU specified in the platform.xml file, the simulator will output a corresponding .trace file, which records information about the execution of tasks on that CPU. In particular, the trace file shows in each column, the simulation time, the task name, the event (START, COMPLETED, CANCELLED, or FAILED), the CPU name, and completion time when applicable.
Use of SimGrid. We chose to implement the BOINC simulator using SimGrid for a number of reasons. First, SimGrid provides a number abstractions and tools that simplify the process of simulating of complex parallel and distributed systems. For example, SimGrid provides abstractions for processes, computing elements, network links, and etc. These abstractions and tools greatly simplified the implementation of the BOINC simulator. Second, we can leverage the proven accuracy of SimGrid’s resource models. For example, SimGrid models allocation of network bandwidth among competing data transfers using a flow-based TCP model for networks that has been shown to be reasonably accurate. Third, SimGrid was implemented in C and using it with BOINC’s C++ source code is straightforward.
APPLICATIONS Bag of Task Applications Applications composed of a set of independent tasks is the most common class of application that one can execute on a Desktop Grid. This class of application is straight-forward to schedule and simple to execute when there is little IO. However, it is a very popular class of application that is used in many scientific domains. In particular, it permits multi-parametric studies, when one application, typically a simulation code is run against a large set of parameters in order to explore a range of possible solutions.
Data Intensive Enabling Data Grids is one of the fundamental efforts of the computational science community as emphasized by projects such as EGEE (Enabling Grigs for E-Science in Europe,) and PPDG (2006). This effort is pushed by the new requirements of E-Science. That is, large communities of researchers collaborate to extract knowledge and information from huge amounts of scientific data. This has lead to the emergence of a new class of application, called data-intensive applications that require secure and coordinated access to large datasets, wide-area transfers and broad distribution of TeraBytes of data while keeping track of multiple data replicas. The Data Grid aims at providing such an infrastructure and services to enable data-intensive applications. Despite the attractiveness of Desktop Grids, little work has
51
Desktop Grids
been done to support data-intensive applications in this context of massively distributed, volatile, shared and heterogeneous resources. Most Desktop Grid systems, like BOINC (Anderson, 2004), XtremWeb (Fedak et al., 2001) and OurGrid (Andrade et al., 2003) rely on a centralized architecture for indexing and distributing the data, and thus potentially face issues with scalability and fault-tolerance. Large data movement across wide-area networks can be costly in terms of performance because bandwidth across the Internet is often limited, variable and unpredictable. Caching data on local workstation storage (Iamnitchi et al., 2006 ; Otoo et al., 2004 ; Vazhkudai et al., 2005) with adequate scheduling strategies (Santos-Neto et al., 2004 ; Wei et al., 2005) to minimize data transfers can improve overall application execution time. Implementing a simple execution principle like “Owner Compute” still requires the system to efficiently locate data and to provide a model for the cost of moving data. Moreover, accurate modeling (Qiu & Srikant, 2004) and forecasting of P2P communication is still a challenging and open issue, and it will be required before one can efficiently execute more demanding types of applications, such as those that require real-time or stream processing.
Long Running Applications Long-running applications are challenging due to the volatility of executing nodes and often require checkpointing services. To achieve their execution it requires local or remote checkpointing to avoid loosing their computational state when a failure occurs.
Real-Time Applications In this paragraph, we focus on enabling soft real-time applications to execute on enterprise desktop Grids; soft real-time applications often have a deadline associated with each task but can afford to miss some of these deadlines. A number of soft real-time applications ranging from information processing of sensor networks (Sensor Networks), real-time video encoding (Rodriguez, Gonzalez, Malumbres), to interactive scientific visualization (Lopez et al., 1999 ; Smallen, Casanova, Berman, 2001) could potentially utilize desktop Grids. An example of such an application that has soft real-time requirements is on-line parallel tomography (Smallen et al., 2001). Tomography is the construction of 3-D models from 2-D projections, and it is common in electron microscopy to use tomography to create 3-D images of biological specimens. On-line parallel tomography applications are embarrassingly parallel as each 2-D projection can be decomposed into independent slices that must be distributed to a set of resources for processing. Each slice is on the order of kilobytes or megabytes in size, and there are typically hundreds or thousands of slices per projection, depending on the size of each projection. Ideally, the processing time of a single projection can be done while the user is acquiring the next image from the microscope, which typically takes several minutes (Hsu, 2005). As such, on-line parallel tomography could potentially be executed on desktop Grids if there were effective method for meeting the application’s relatively stringent time demands.
Network-Intensive Applications There are a few desktop Grid applications that are not CPU or data intensive; they use other resources available on the compute node. The execution time is not limited by processing speed, the amount of available memory, or communication times but by the availability of these resources.
52
Desktop Grids
The network is one of these resources. Malicious distributed applications (zombies PC) use it for sending a huge amount of data: sending SPAM, distributed attack targeting a given host. But network may also be useful for web spiders. For example, YaCy is a P2P-based search engine. On each volunteer resources, a web crawler collects data from the web that are locally indexed and stored. A local client is available for retrieving search results from other computing nodes through a DHT. Those tasks often require special scheduling policy from the desktop Grid because usual criteria cannot be used. For example, BOINC has support for non CPU-intensive (a special mode that applies to a whole project) tasks but some limitations are imposed: First, the client doesn’t maintain a cache of task to run: there is only one task present on the client at a given time. This is due to the fact that BOINC can’t estimate completion time by measuring CPU usage as it does for normal projects. Second, non CPU-intensive applications have to restrict there CPU usage to the minimum because there are some other CPU intensive task running at the same time: BOINC doesn’t mix scheduling policies.
CONCLUSION Thorough this chapter, we have presented an historical review of Desktop Grid System as well as the state-of-the-art of scientific researches and most recent technological innovations. In the late 90’s, the history of Desktop Grid System has started with simple computational applications featuring trivial and massive parallelism. Systems were based on common and rough-and-ready technologies, such as Web server with servers-side scripts and Java applets. Despite or because of this seeming architectural simplicity, these systems grew rapidly to appear amongst the largest distributed applications. In the early 2000’s, the challenge of gathering TeraFlops of volunteers’ PCs was met, attracting the attention of the mainstream media. Several high-tech companies have been built-up to sell services and commercial systems. In some sense, Desktop Grids systems appeared to be the most successful amongst the Grid applications to popularize and democratize the Grids to people at large. During the first decade of research in Desktop Grids systems, a huge effort has been made to bring this paradigm to a common facility usable for a broad range of scientific and industrial applications. As a consequence, this effort has led to a impressive set of innovations which has improved Desktop Grids system in term of reliability (for instance fault-tolerant communication libraries, distributed checkpointing), of data management (use of P2P protocols to distribute and manage data), of security (result certification, sandboxing) and performance (new classes of scheduling heuristics based on replication and evaluation of host availability). What are the perspectives of Desktop Grid Systems? The singularity of DG system is the location the are, at the frontier between Grid systems and Internet. As DG systems will become more efficient and more reliable, they will incorporate more deeply into Grid system. On one hand this will enable more scientists to benefit from this technology. On the other hand, the price will be an increased complexity in term of management. Has such, future of DG system will certainly follow the evolution of the Internet towards more users provided content, social network, distributed intelligence etc... Desktop Grid computing may also have a role to play in the context of Could computing. Currently the service infrastructure envisioned for Clouds is designed from large scale data centers. However, like for P2P systems, an approach of Cloud computing based on community of users sharing resources for free may counter balance the actual trend toward commercial service infrastructures. Of course, using
53
Desktop Grids
Desktop Grid as an underlying technology and infrastructure for Cloud computing raises a lot of research issues and opens exciting perspectives for Desktop Grids.
REFERENCES Abdennadher, N., & Boesch, R. (2006, August). A scheduling algorithm for high performance peer-topeer platform. In W. Lehner, N. Meyer, A. Streit, & C. Stewart (Eds.), Coregrid Workshop, Euro-Par 2006 (p. 126-137). Dresden, Germany: Springer. Alexandrov, A. D., Ibel, M., Schauser, K. E., & Scheiman, C. (1997, April). SuperWeb: Towards a global web-based parallel computing infrastructure. In Proceedings of the 11th IEEE International Parallel Processing Symposium (IPPS). Anderson, D. (2004). BOINC: A system for public-resource computing and storage. In Proceedings of the 5th IEEE/ACM International Grid Workshop, Pittsburgh, PA. Anderson, D., & Fedak, G. (2006). The computational and storage potential of volunteer computing. In Proceedings of The IEEE International Symposium on Cluster Computing and The Grid (CCGRID’06). Anderson, D. P., Cobb, J., Korpela, E., Lebofsky, M., & Werthimer, D. (2002, November). Seti@ home: An experiment in public-resource computing. Communications of the ACM, 45(11), 56–61. doi:10.1145/581571.581573 Andrade, N., Cirne, W., Brasileiro, F., & Roisenberg, P. (2003, June). OurGrid: An approach to easily assemble grids with equitable resource sharing. In Proceedings of the 9th Workshop on Job Scheduling Strategies for Parallel Processing. Andrzejak, A., Domingues, P., & Silva, L. (2006). Predicting Machine Availabilities in Desktop Pools. In IEEE/IFIP Network Operations and Management Symposium (pp. 225–234). Andrzejak, A., Kondo, D., & Anderson, D. P. (2008). Ensuring collective availability in volatile resource pools via forecasting. In 19th Ifip/Ieee Distributed Systems: Operations And Management (DSOM 2008). Samos Island, Greece. Araujo, F., Domingues, P., Kondo, D., & Silva, L. M. (2008, April). Using cliques of nodes to store desktop grid checkpoints. In Coregrid Integration Workshop, Crete, Greece. Balaton, Z., Gombas, G., Kacsuk, P., Kornafeld, A., Kovacs, J., & Marosi, A. C. (2007, March 26-30). Sztaki desktop grid: a modular and scalable way of building large computing grids. In Proceedings of the 21st International Parallel And Distributed Processing Symposium, Long Beach, CA. Baldassari, J., Finkel, D., & Toth, D. (2006, November 13-15). Slinc: A framework for volunteer computing. In Proceedings of the 18th Iasted International Conference On Parallel And Distributed Computing And Systems (PDCS 2006). Dallas, TX. Barak, A., Guday, S., & R., W. (1993). The MOSIX Distributed Operating System, Load Balancing for UNIX (Vol. 672). Berlin: Springer-Verlag.
54
Desktop Grids
Baratloo, A., Karaul, M., Kedem, Z., & Wyckoff, P. (1996). Charlotte: Metacomputing on the Web. In Proceeidngs of the 9th International Conference On Parallel And Distributed Computing Systems (PDCS-96). Bassi, A., Beck, M., Fagg, G., Moore, T., Plank, J. S., & Swany, M. (2002). The Internet BackPlane Protocol: A Study in Resource Sharing. In Second ieee/acm international symposium on cluster computing and the grid, Berlin, Germany. Berman, F., Wolski, R., Figueira, S., Schopf, J., & Shao, G. (1996). Application-Level Scheduling on Distributed Heterogeneous Networks. In Proc. of supercomputing’96, Pittsburgh, PA. Bhatt, S. N., Chung, F. R. K., Leighton, F. T., & Rosenberg, A. L. (1997). An optimal strategies for cycle-stealing in networks of workstations. IEEE Transactions on Computers, 46(5), 545–557. doi:10.1109/12.589220 Bolosky, W., Douceur, J., Ely, D., & Theimer, M. (2000). Feasibility of a Serverless Distributed file System Deployed on an Existing Set of Desktop PCs. In Proceedings of sigmetrics. Brecht, T., Sandhu, H., Shan, M., & Talbot, J. (1996). Paraweb: towards world-wide supercomputing. In Ew 7: Proceedings of the 7th workshop on acm sigops european workshop (pp. 181–188). New York: ACM. Butt, A. R., Johnson, T. A., Zheng, Y., & Hu, Y. C. (2004). Kosha: A Peer-to-Peer Enhancement for the Network File System. In Proceeding of International Symposium On Supercomputing SC’04. Camiel, N., London, S., Nisan, N., & Regev, O. (1997, April). The PopCorn Project: Distributed computation over the Internet in Java. In Proceedings of the 6th international world wide web conference. Cappello, F., Djilali, S., Fedak, G., Herault, T., Magniette, F., & Néri, V. (2004). Computing on large scale distributed systems: Xtremweb architecture, programming models, security, tests and convergence with grid. Future Generation Computer Science (FGCS). Cappello, P., Christiansen, B., Ionescu, M., Neary, M., Schauser, K., & Wu, D. (1997). Javelin: InternetBased Parallel Computing Using Java. In Proceedings of the sixth acm sigplan symposium on principles and practice of parallel programming. Casanova, H., Legrand, A., & Quinson, M. SimGrid: a Generic Framework for Large-Scale Distributed Experimentations. In Proceedings of the 10th ieee international conference on computer modelling and simulation (uksim/eurosim’08). Casanova, H., Legrand, A., Zagorodnov, D., & Berman, F. (2000, May). Heuristics for Scheduling Parameter Sweep Applications in Grid Environments. In Proceedings of the 9th heterogeneous computing workshop (hcw’00) (pp. 349–363). Casanova, H., Obertelli, G., Berman, F., & Wolski, R. (2000, Nov.). The AppLeS Parameter Sweep Template: User-Level Middleware for the Grid. In Proceedings of supercomputing 2000 (sc’00). Chien, A., Calder, B., Elbert, S., & Bhatia, K. (2003). Entropia: Architecture and performance of an enterprise desktop grid system. Journal of Parallel and Distributed Computing, 63, 597–610. doi:10.1016/ S0743-7315(03)00006-6
55
Desktop Grids
Cirne, W., Brasileiro, F., Andrade, N., Costa, L., Andrade, A., & Novaes, R. (2006, September). Labs of the world, unite!!! Journal of Grid Computing, 4(3), 225–246. doi:10.1007/s10723-006-9040-x Cohen, B. (2003). Incentives build robustness in BitTorrent. In Workshop on economics of peer-to-peer systems, Berkeley, CA. Costa, F., Silva, L., Fedak, G., & Kelley, I. (2008, in press). Optimizing the Data Distribution Layer of BOINC with BitTorrent. In 2nd workshop on desktop grids and volunteer computing systems (pcgrid 2008), Miami, FL. Dean, J., & Ghemawat, S. (2004). MapReduce: Simplified Data Processing on Large Clusters. In Osdi’04: Sixth symposium on operating system design and implementation, (pp. 137–150). San Francisco, CA. Domingues, P., Araujo, F., & Silva, L. M. (2006, December). A dht-based infrastructure for sharing checkpoints in desktop grid computing. In Conference on e-science and grid computing (escience ’06), Amsterdam, The Netherlands. Draves, S. (2005, March). The electric sheep screen-saver: A case study in aesthetic evolution. In 3rd european workshop on evolutionary music and art. Fedak, G., & Germain, C. N’eri, V., & Cappello, F. (2001, May). XtremWeb: A Generic Global Computing System. In Proceedings of the ieee international symposium on cluster computing and the grid (ccgrid’01). Fedak, G., He, H., & Cappello, F. (2008, November). BitDew: A Programmable Environment for LargeScale Data Management and Distribution. In Proceedings of the acm/ieee supercomputing conference (sc’08), Austin, TX. Federation, M. D. The Biomedical Informatics Research Network (2003). In I. Foster & C. Kesselman (Eds.), The grid, blueprint for a new computing infrastructure (2nd ed.). San Francisco: Morgan Kaufmann. Fernandess, Y., & Malkhi, D. (2006). On Collaborative Content Distribution using Multi-Message Gossip. In Proceedings of the international parallel and distributed processing symposium. Rhodes Island, Greece: IEEE. Foster, I., & Kesselman, C. (Eds.). (1999). The Grid: Blueprint for a New Computing Infrastructure. San Francisco, USA: Morgan Kaufmann Publishers, Inc. Foster, I. T., & Iamnitchi, A. (2003). On death, taxes, and the convergence of peer-to-peer and grid computing. 2735, 118-128. Ghare, G., & Leutenegger, L. (2004, June). Improving Speedup and Response Times by Replicating Parallel Programs on a SNOW. In Proceedings of the 10th workshop on job scheduling strategies for parallel processing. Ghormley, D., Petrou, D., Rodrigues, S., Vahdat, A., & Anderson, T. (1998, July). GLUnix: A global layer unix for a network of workstations. Software, Practice & Experience, 28(9), 929. doi:10.1002/ (SICI)1097-024X(19980725)28:9<929::AID-SPE183>3.0.CO;2-C
56
Desktop Grids
Gkantsidis, C., & Rodriguez, P. (2005, March). Network Coding for Large Scale Content Distribution. In Proceedings of ieee/infocom 2005, Miami, USA. Heien, E., Fujimoto, N., & Hagihara, K. (2008). Computing low latency batches with unreliable workers in volunteer computing environments. In Pcgrid. Hsu, A. (2005, March). Personal communication. Iamnitchi, A., Doraimani, S., & Garzoglio, G. (2006). Filecules in High-Energy Physics: Characteristics and Impact on Resource Management. In proceeding of 15th ieee international symposium on high performance distributed computing hpdc 15, Paris. Iamnitchi, A., Foster, I. T., & Nurmi, D. (2002). A peer-to-peer approach to resource location in grid environments. In Hpdc (p. 419). Jin, H., Xiong, M., Wu, S., & Zou, D. (2006). Replica Based Distributed Metadata Management in Grid Environment. Computational Science (LNCS 3944, pp. 1055-1062). Berlin: Springer-Verlag. Jung, E. B., Choi, S.-J., Baik, M.-S., Hwang, C.-S., Park, C.-Y., & Young, S. (2005). Scheduling scheme based on dedication rate in volunteer computing environment. In Third international symposium on parallel and distributed computing (ispdc 2005), Lille, France. Kim, J.-S., Nam, B., Keleher, P. J., Marsh, M. A., Bhattacharjee, B., & Sussman, A. (2006). Resource discovery techniques in distributed desktop grid environments. In Grid (pp. 9-16). Kondo, D., Araujo, F., Malecot, P., Domingues, P., Silva, L. M., & Fedak, G. (2006). Characterizing result errors in internet desktop grids (Tech. Rep. No. INRIA-HALTech Report 00102840), INRIA, France. Kondo, D., Chien, A., & H., C. (2004, November). Rapid Application Turnaround on Enterprise Desktop Grids. In Acm conference on high performance computing and networking, sc2004. Kondo, D., Chien, A. A., & Casanova, H. (2007). Scheduling task parallel applications for rapid turnaround on enterprise desktop grids. Journal of Grid Computing, 5(4), 379–405. doi:10.1007/s10723007-9063-y Kondo, D., Fedak, G., Cappello, F., Chien, A. A., & Casanova, H. (2006, December). On Resource Volatility in Enterprise Desktop Grids. In Proceedings of the 2nd IEEE International Conference On E-Science And Grid Computing (eScience’06) (pp. 78–86). Amsterdam, Netherlands. Kondo, D., Taufer, M., Brooks, C., Casanova, H., & Chien, A. (2004, April). Characterizing and evaluating desktop grids: An empirical study. In Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’04). Lee, S., Ren, X., & Eigenmann, R. (2008). Efficient content search in ishare, a p2p based internet-sharing system. In PCGRID. Leutenegger, S., & Sun, X. (1993). Distributed computing feasibility in a non-dedicated homogeneous distributed system. In Proceedings of SC’93, Portland, OR. Litzkow, M., Livny, M., & Mutka, M. (1988). Condor - A hunter of idle workstations. In Proceedings of the 8th International Conference Of Distributed Computing Systems (ICDCS).
57
Desktop Grids
Lodygensky, O., Fedak, G., Cappello, F., Neri, V., Livny, M., & Thain, D. (2003). XtremWeb & Condor: Sharing resources between Internet connected condor pools. In Proceedings of CCGRID’2003, Third International Workshop On Global And Peer-To-Peer Computing (GP2PC’03) (pp. 382–389). Tokyo, Japan. Lopez, J., Aeschlimann, M., Dinda, P., Kallivokas, L., Lowekamp, B., & O’Hallaron, D. (1999, June). Preliminary report on the design of a framework for distributed visualization. In Proceedings of the international conference on parallel and distributed processing techniques and applications (PDPTA’99) (pp. 1833–1839). Las Vegas, NV. Malécot, P., Kondo, D., & Fedak, G. (2006, June). Xtremlab: A system for characterizing internet desktop grids. In Poster in the 15th ieee international symposium on high performance distributed computing hpdc’06. Paris, France. Mattson, T., Sanders, B., & Massingill, B. (2004). Patterns for parallel programming. New York: Addison-Wesley. Maymounkov, P., & Mazières, D. (2002). Kademlia: A Peer-to-peer Information System Based on the XOR Metric. In Proceedings of the 1st international workshop on peer-to-peer systems (iptps’02) (pp. 53–65). Mutka, M., & Livny, M. (1991, July). The available capacity of a privately owned workstation environment. Performance Evaluation, 4(12). Mutka, M. W., & Livny, M. (1987). Profiling workstations’ available capacity for remote execution. In Proceedings of performance-87, the 12th ifip w.g. 7.3 international symposium on computer performance modeling, measurement and evaluation. Brussels, Belgium. Myers, D. S., Bazinet, A. L., & Cummings, M. P. (2008). Expanding the reach of grid computing: combining globus- and boinc-based systems. In Grids for Bioinformatics and Computational Biology. New York: Wiley. Nisan, N., London, S., Regev, O., & Camiel, N. (1998). Globally distributed computation over the internet - the popcorn project. In International conference on distributed computing systems 1998 (p. 592). New York: IEEE Computer Society. Otoo, E., Rotem, D., & Romosan, A. (2004). Optimal File-Bundle Caching Algorithms for Data-Grids. In Sc ’04: Proceedings of the 2004 acm/ieee conference on supercomputing (p. 6). Washington, DC: IEEE Computer Society. Pedroso, J., Silva, L., & Silva, J. (1997, June). Web-based metacomputing with JET. In Proc. of the acm ppopp workshop on java for science and engineering computation. PPDG. (2006). From fabric to physics (Tech. Rep.). The Particle Physics Data Grid. Pruyne, J., & Livny, M. (1996). A Worldwide Flock of Condors: Load Sharing among Workstation Clusters. Journal on Future Generations of Computer Systems, 12. Qiu, D., & Srikant, R. (2004). Modeling and performance analysis of bittorrent-like peer-to-peer networks. Computer Communication Review, 34(4), 367–378. doi:10.1145/1030194.1015508
58
Desktop Grids
Raicu, I., Zhao, Y., Dumitrescu, C., Foster, I., & Wilde, M. (2007). Falkon: a fast and light-weight task execution framework. In Ieee/acm supercomputing. Raman, R., Livny, M., & Solomon, M. H. (1998). Matchmaking: Distributed resource management for high throughput computing. In Hpdc (p. 140). Rhea, S. C., Eaton, P. R., Geels, D., Weatherspoon, H., Zhao, B. Y., & Kubiatowicz, J. (2003). Pond: The oceanstore prototype. In Fast. Rodriguez, A., Gonzalez, A., & Malumbres, M. P. Performance evaluation of parallel mpeg-4 video coding algorithms on clusters of workstations. International Conference on Parallel Computing in Electrical Engineering (PARELEC’04), 354-357. Rowstron, A., & Druschel, P. (2001, November). Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. In Proceedings of the 18th ifip/acm international conference on distributed systems platforms (middleware 2001), Heidelberg, Germany. Santos-Neto, E., Cirne, W., Brasileiro, F., & Lima, A. (2004). Exploiting Replication and Data Reuse to Efficiently Schedule Data-intensive Applications on Grids. In Proceedings of the 10th workshop on job scheduling strategies for parallel processing. Sarmenta, L. F. G. (2002). Sabotage-tolerance mechanisms for volunteer computing systems. Future Generation Computer Systems, 18(4), 561–572. doi:10.1016/S0167-739X(01)00077-2 Sarmenta, L. F. G., & Hirano, S. (1999). Bayanihan: Building and studying volunteer computing systems using Java. Future Generation Computer Systems, 15(5/6), 675-686. Sensor Networks. Retrieved from http://www.sensornetworks.net.au/network.html Sfiligoi, K. O., Venekamp, G., Yocum, D., Groep, D., & Petravick, D. (2007). Addressing the Pilot security problem with gLExec (Tech. Rep. No. FERMILAB-PUB-07-483-CD). Fermi National Laboratory, Batavia, IL. Shirts, M., & Pande, V. (2000). Screen savers of the world, unite! Science, 290, 1903–1904. doi:10.1126/ science.290.5498.1903 Shoch, J. F., & Hupp, J. A. (1982). 03). The “worm” programs - early experience with a distributed computation. Communications of the ACM, 3(25). Smallen, S., Casanova, H., & Berman, F. (2001, Nov.). Tunable on-line parallel tomography. In Proceedings of Supercomputing’01, Denver, CO. Sonnek, J. D., Nathan, M., Chandra, A., & Weissman, J. B. (2006). Reputation-based scheduling on unreliable distributed infrastructures. In ICDCS (p. 30). Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., & Balakrishnan, H. (2001, August). Chord: A scalable peer-to-peer lookup service for internet applications. In Proceedings of the ACM SIGCOMM ’01 Conference, San Diego, CA. Taufer, M., Anderson, D., Cicotti, P., & III, C. L. B. (2005). Homogeneous redundancy: a technique to ensure integrity of molecular simulation results using public computing. In Proceedings of The International Heterogeneity In Computing Workshop.
59
Desktop Grids
Thain, D., & Livny, M. (2004). Building reliable clients and services. In The grid2 (pp. 285–318). San Francisco: Morgan Kaufman. The seti@home project. Retrieved from http://setiathome.ssl.berkeley.edu/ Tsaregorodtsev, A., Garonne, V., & Stokes-Rees, I. (2004). Dirac: A scalable lightweight architecture for high throughput computing. In Fifth IEEE/ACM International Workshop On Grid Computing (Grid’04). Vazhkudai, S., & Ma, X. V. F., Strickland, J., Tammineedi, N., & Scott, S. (2005). Freeloader:scavenging desktop storage resources for scientific data. In Proceedings of Supercomputing 2005 (SC’05), Seattle, WA. Wei, B., Fedak, G., & Cappello, F. (2005). scheduling independent tasks sharing large data distributed with BitTorrent. In The 6th IEEE/ACM International Workshop On Grid Computing, 2005, Seattle, WA. Yacy - distributed p2p-based Web indexing. Zhao, S., & Lo, V. (2001, May). Result Verification and Trust-based Scheduling in Open Peer-to-Peer Cycle Sharing Systems. In Proceedings of Ieee Fifth International Conference on Peer-To-Peer Systems. Zhou, D., & Lo, V. M. (2006). Wavegrid: A scalable fast-turnaround heterogeneous peer-based desktop grid system. In IPDPS.
KEY TERMS AND DEFINITIONS Cycle Stealing: Consists in using the unused cycles of desktop workstations. Participating workstations also donate some supporting amount of disk storage space, RAM, and network bandwidth, in addition to raw CPU power. The volunteer must get back full usage of its resources with no delay when it request them. Desktop Grid: A computing environment making use of Desktop computers connected via the Internet. Desktop Grids are not used only for voluntary computing projects, but also for enterprise Grids. connected via non dedicated network connection Master-Worker Paradigm: Consists in two entities: a master and several workers. The master decomposes the problem into smaller tasks and distributes them among workers. The worker receives the task from the master, executes it and sends back the result to the master. Result Certification: In distributed computing the result certification is a mechanism that aims to validate the results computed by volatile and possibly malicious hosts. The most common mechanisms for result validation are: the majority voting, spot-checking and credibility-based technique. Volunteer Computing: An arrangement in which computer owners provide there computing resources to one or more projects that are using them to do distributed computing. Those Desktop Grids are made of plenty tiny and uncontrollable administrative domains.
60
Desktop Grids
ENDNOTES 1 United Devices Inc., http://www.ud.com/ 2 Platform Computing Inc., http://www.platform.com/ 3 Mesh Technologies, http://www.meshtechnologies.com/ 4 The COSM project, http://www.mithral.com/projects/cosm/ 5 EINSTEIN@home, http://einstein.phys.uwm.edu 6 The Great Internet Mersenne Prime Search, http://www.mersenne.org/ 7 Distributed.net, www.distributed.net 8 Electric Sheep, http://electricsheep.org/ 9 XtremWeb-CH’s website, http://www.xtremwebch.net/ 10 Simple Light-weight Infrastructure for Network Computing, http://slinc.sourceforge.net/ 11 XtremLab: A System for Characterizing Internet Desktop Grids, http://xtremlab.lri.fr
61
62
Chapter 4
Porting Applications to Grids1 Wolfgang Gentzsch EU Project DEISA and Board of Directors of the Open Grid Forum, Germany
ABSTRACT Aim of this chapter is to guide developers and users through the most important stages of implementing software applications on Grid infrastructures, and to discuss important challenges and potential solutions. Those challenges come from the underlying grid infrastructure, like security, resource management, and information services; the application data, data management, and the structure, volume, and location of the data; and the application architecture, monolithic or workflow, serial or parallel. As a case study, the author presents the DEISA Distributed European Infrastructure for Supercomputing Applications and describes its DEISA Extreme Computing Initiative DECI for porting and running scientific grand challenge applications. The chapter concludes with an outlook on Compute Clouds, and suggests ten rules of building a sustainable grid as a prerequisite for long-term sustainability of the grid applications.
INTRODUCTION Over the last 40 years, the history of computing is deeply marked of the affliction of the application developers who continuously are porting and optimizing their application codes to the latest and greatest computing architectures and environments. After the von-Neumann mainframe came the vector computer, then the shared-memory parallel computer, the distributed-memory parallel computer, the very-long-instruction word computer, the workstation cluster, the meta-computer, and the Grid (never fear, it continues, with SOA, Cloud, Virtualization, Many-core, and so on). There is no easy solution to this, and the real solution would be a separation of concerns between discipline-specific content and domain-independent software and hardware infrastructure. However, this often comes along with a loss DOI: 10.4018/978-1-60566-661-7.ch004
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Porting Applications to Grids
of performance stemming from the overhead of the infrastructure layers. Recently, users and developers face another wave of complex computing infrastructures: the Grid. Let’s start with answering the question: What is a Grid? Back in 1998, Ian Foster and Carl Kesselman (1998) attempted the following definition: “A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities.” In a subsequent article (Foster, 2002), “The Anatomy of the Grid,” Ian Foster, Carl Kesselman, and Steve Tuecke changed this definition to include social and policy issues, stating that Grid computing is concerned with “coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations.” The key concept is the ability to negotiate resource-sharing arrangements among a set of participating parties (providers and consumers) and then to use the resulting resource pool for some purpose. They continued: “The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problem-solving and resource-brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals and/or institutions defined by such sharing rules form what we call a virtual organization.” This author’s concern, from the beginning (Gentzsch, 2002), was that the new definition seemed very ambitious, and as history has proven, many of the Grid projects with a focus on these ambitious objectives did not lead to a sustainable grid production environment, so far. We can only repeat that the simpler the grid infrastructure, and the easier to use, and the sharper its focus, the bigger is its chance for success. And it is for a good reason (which we will explain in the following) that currently the so-called Clouds are becoming more and more popular (Amazon, 2007). Over the last ten years, hundreds of applications in science, industry and enterprises have been ported to Grid infrastructures, mostly prototypes in the early definition of Foster & Kesselman (1998). Each application is unique in that it solves a specific problem, based on modeling, for example, a specific phenomenon in nature (physics, chemistry, biology, etc.), presented as a mathematical formula together with appropriate initial and boundary conditions, represented by its discrete analogue using sophisticated numerical methods, translated into a programming language computers can understand, adjusted to the underlying computer architecture, embedded in a workflow, and accessible remotely by the user through a secure, transparent and application-specific portal. In just these very few words, this summarizes the wide spectrum and complexity we face in problem solving on grid infrastructures. The user (and especially the developer) faces several layers of complexity when porting applications to a computing environment, especially to a compute or data grid of distributed networked nodes ranging from desktops to supercomputers. These nodes, usually, consist of several to many loosely or tightly coupled processors and, more and more, these processors contain few to many cores. To run efficiently on such systems, applications have to be adjusted to the different layers, taking into account different levels of granularity, from fine-grain structures deploying multi-core architectures at processor level to the coarse granularity found in application workflows representing for example multi-physics applications. Not enough, the user has to take into account the specific requirements of the grid, coming from the different components of the grid services architecture, such as security, resource management, information services, and data management. Obviously, in this article, it seems impossible to present and discuss the complete spectrum of applications and their adaptation and implementation on Grids. Therefore, we restrict ourselves in the following to briefly describe the different application classes, present a checklist (or classification) with
63
Porting Applications to Grids
respect to grouping applications according to their appropriate grid-enabling strategy. Also, for lack of space, here, we are not able to include a discussion of mental, social, or legal aspects which sometimes might be the knock-out criteria for running applications on a grid. Other show-stoppers such as sensitive data, security concerns, licensing issues, and intellectual property, were discussed in some detail in Gentzsch (2007a). In the following, we will consider the main three areas of impact on porting applications to grids: infrastructure issues, data management issues, and application architecture issues. These issues can have an impact on effort and success of porting, on the resulting performance of the grid application, and on the user-friendly access to the resources, the grid services, the application, the data, and the final processing results, among others.
APPLICATIONS AND THE GRID INFRASTRUCTURE As mentioned before, the successful porting of an application to a grid environment highly depends on the underlying distributed resource infrastructure. The main services components offered by a grid infrastructure are security, resource management, information services, and data management. Bart Jacob et al. suggest that each of these components can affect the application architecture, its design, deployment, and performance. Therefore, the user has to go through the process of matching the application (structure and requirements) with those components of the grid infrastructure, as described here, closely following the description in Jacob at al. (2003).
Applications and Security The security functions within the grid architecture are responsible for the authentication and authorization of the user, and for the secure communication between the grid resources. Fortunately, these functions are an inherent part of most grid infrastructures and don’t usually affect the applications themselves, supposed the user (and thus the user’s application) is authorized to use the required resources. Also, security from an application point of view might be taken into account in the case that sensitive data is passed to a resource to be processed by a job and is written to the local disk in a non-encrypted format, and other users or applications might have access to that data.
Applications and Resource Management The resource management component provides the facilities to allocate a job to a particular resource, provides a means to track the status of the job while it is running and its completion information, and provides the capability to cancel a job or otherwise manage it. In conjunction with Monitoring and Discovery Service (described below) the application must ensure that the appropriate target resource(s) are used. This requires that the application accurately specifies the required environment (operating system, processor, speed, memory, and so on). The more the application developer can do to eliminate specific dependencies, the better the chance that an available resource can be found and that the job will complete. If an application includes multiple jobs, the user must understand (and maybe reduce) their interdependencies. Otherwise, logic has to be built to handle items such as inter-process communication, sharing of data, and concurrent job submissions. Finally, the job management provides mechanisms to
64
Porting Applications to Grids
query the status of the job as well as perform operations such as canceling the job. The application may need to utilize these capabilities to provide feedback to the user or to clean up or free up resources when required. For instance, if one job within an application fails, other jobs that may be dependent on it may need to be cancelled before needlessly consuming resources that could be used by other jobs.
Applications and Resource Information Services An important part of the process of grid-enabling an application is to identify the appropriate (if not optimal) resources needed to run the application, i.e. to submit the respective job to. The service which maintains and provides the knowledge about the grid resources is the Grid Information Service (GIS), also known as the Monitoring and Discovery Service (e.g. MDS in Globus [xx]. MDS provides access to static and dynamic information of resources. Basically, it contains the following components: • • • •
Grid Resource Information Service (GRIS), the repository of local resource information derived from information providers. Grid Index Information Service (GIIS), the repository that contains indexes of resource information registered by the GRIS and other GIISs. Information providers, translate the properties and status of local resources to the format defined in the schema and configuration files. MDS client which initially performs a search for information about resources in the grid environment.
Resource information is obtained by the information provider and it is passed to GRIS. GRIS registers its local information with the GIIS, which can optionally also register with another GIIS, and so on. MDS clients can query the resource information directly from GRIS (for local resources) and/or a GIIS (for grid-wide resources). It is important to fully understand the requirements for a specific job so that the MDS query can be correctly formatted to return resources that are appropriate. The user has to ensure that the proper information is in MDS. There is a large amount of data about the resources within the grid that is available by default within the MDS. However, if the application requires special resources or information that is not there by default, the user may need to write her own information providers and add the appropriate fields to the schema. This may allow the application or broker to query for the existence of the particular resource/requirement.
Applications and Data Management Data management is concerned with collectively maximizing the use of the limited storage space, networking bandwidth, and computing resources. Within the application, data requirements have been built in which determine, how data will be move around the infrastructure or otherwise accessed in a secure and efficient manner. Standardizing on a set of grid protocols will allow to communicate between any data source that is available within the software design. Especially data intensive applications often have a federated database to create a virtual data store or other options including Storage Area Networks, network file systems, and dedicated storage servers. Middleware like the Globus Toolkit provide GridFTP and Global Access to Secondary Storage data transfer utilities in the grid environment. The
65
Porting Applications to Grids
GridFTP facility (extending the FTP File Transfer Protocol) provides secure and reliable data transfer between grid hosts. Developers and users face a few important data management issues that need to be considered in application design and implementation. For large datasets, for example, it is not practical and may be impossible to move the data to the system where the job will actually run. Using data replication or otherwise copying a subset of the entire dataset to the target system may provide a solution. If the grid resources are geographically distributed with limited network connection speeds, design considerations around slow or limited data access must be taken into account. Security, reliability, and performance become an issue when moving data across the Internet. When the data access may be slow or prevented one has to build the required logic to handle this situation. To assure that the data is available at the appropriate location by the time the job requires it, the user should schedule the data transfer in advance. One should also be aware of the number and size of any concurrent transfers to or from any one resource at the same time. Beside the above described main requirements for applications for running efficiently on a grid infrastructure, there are a few more issues which are discussed in Jacob (2003), such as scheduling, load balancing, grid broker, inter-process communication, and portals for easy access, and non-functional requirements such as performance, reliability, topology aspects, and consideration of mixed platform environments.
The Simple API for Grid Applications (SAGA) Among the many efforts in the grid community to develop tools and standards which simplify the porting of applications to Grids by enabling the application to make easy use of the Grid middleware services as described above, one of the more predominant ones is SAGA, a high-level Application Programmers Interface (API), or programming abstraction, defined by the Open Grid Forum (OGF, 2008), an international committee that coordinates standardization of Grid middleware and architectures. SAGA intends to simplify the development of grid-enabled applications, even for scientists without any background in computer science or grid computing. Historically, SAGA was influenced by the work on the GAT Grid Application Toolkit, a C-based API developed in the EU-funded project GridLab (GAT, 2005). The purpose of SAGA is two-fold: 1. 2.
Provide a simple API that can be used with much less effort compared to the interfaces of existing grid middleware. Provide a standardized, portable, common interface for the various grid middleware systems.
According to Goodale (2008) SAGA facilitates rapid prototyping of new grid applications by allowing developers a means to concisely state very complex goals using a minimum amount of code. SAGA provides a simple, POSIX-style API to the most common Grid functions at a sufficiently highlevel of abstraction so as to be able to be independent of the diverse and dynamic Grid environments. The SAGA specification defines interfaces for the most common Grid-programming functions grouped as a set of functional packages. Version 1.0 (Goodale, 2008) defines the following packages: •
66
File package - provides methods for accessing local and remote file systems, browsing directories, moving, copying, and deleting files, setting access permissions, as well as zero-copy reading and writing
Porting Applications to Grids
•
•
• •
Replica package - provides methods for replica management such as browsing logical file systems, moving, copying, deleting logical entries, adding and removing physical files from a logical file entry, and search logical files based on attribute sets. Job package - provides methods for describing, submitting, monitoring, and controlling local and remote jobs. Many parts of this package were derived from the largely adopted DRMAA [11] specification. Stream package - provides methods for authenticated local and remote socket connections with hooks to support authorization and encryption schemes. RPC package - is an implementation of the OGF GridRPC API definition and provides methods for unified remote procedure calls.
The two critical aspects of SAGA are its simplicity of use and the fact that it is well on the road to becoming a community standard. It is important to note, that these two properties are provide the added value of using SAGA for Grid application development. Simplicity arises from being able to limit the scope to only the most common and important grid-functionality required by applications. There a major advantages arising from its simplicity and imminent standardization. Standardization represents the fact that the interface is derived from a wide-range of applications using a collaborative approach and the output of which is endorsed by the broader community. More information about the SAGA C++ Reference Implementation (developed at the Center for Computation and Technology at the Louisiana State University) and various aspects of grid enabling toolkits is available on the SAGA implementation home page (SAGA, 2006). It also provides additional information with regard to different aspects of grid enabling toolkits.
GRID APPLICATIONS AND DATA Any e-science application at its core has to deal with data, from input data (e.g. in the form of output data from sensors, or as initial or boundary data), to processing data and storing of intermediate results, to producing final results (e.g. data used for visualization). Data has a strong influence on many aspects of the design and deployment of an application and determines whether a grid application can be successfully ported to the grid. Therefore, in the following, we present a brief overview of the main data management related aspects, tasks and issues which might affect the process of grid-enabling an application, such as data types and size, shared data access, temporary data spaces, network bandwidth, time-sensitive data, location of data, data volume and scalability, encrypted data, shared file systems, databases, replication, and caching. For a more in-depth discussion of data management related tasks, issues, and techniques, we refer to Bart Jacob’s tutorial on application enabling with Globus (Jacob, 2003).
Shared Data Access Sharing data access can occur with concurrent jobs and other processes within the network. Access to data input and the data output of the jobs can be of various kinds. During the planning and design of the grid application, potential restrictions on the access of databases, files, or other data stores for either read or write have to be considered. The installed policies need to be observed and sufficient access rights have to be granted to the jobs. Concerning the availability of data in shared resources,
67
Porting Applications to Grids
it must be assured that at run-time of the individual jobs the required data sources are available in the appropriate form and at the expected service level. Potential data access conflicts need to be identified up front and planned for. Individual jobs should not try to update the same record at the same time, nor dead lock each other. Care has to be taken for situations of concurrent access and resolution policies imposed. The use of federated databases may be useful in data grids where jobs must handle large amounts of data in various different data stores, you. They offer a single interface to the application and are capable of accessing data in large heterogeneous environments. Federated database systems contain information about location (node, database, table, record) and access methods (SQL, VSAM, privately defined methods) of connected data sources. Therefore, a simplified interface to the user (a grid job or other client) requires that the essential information for a request should not include the data source, but rather use a discovery service to determine the relevant data source and access method.
Data Topology Issues about the size of the data, network bandwidth, and time sensitivity of data determine the location of data for a grid application. The total amount of data within the grid application may exceed the amount of data input and output of the grid application, as there can be a series of sub-jobs that produce data for other sub-jobs. For permanent storage the grid user needs to be able to locate where the required storage space is available in the grid. Other temporary data sets that may need to be copied from or to the client also need to be considered. The amount of data that has to be transported over the network is restricted by available bandwidth. Less bandwidth requires careful planning of the data traffic among the distributed components of a grid application at runtime. Compression and decompression techniques are useful to reduce the data amount to be transported over the network. But in turn, it raises the issue of consistent techniques on all involved nodes. This may exclude the utilization of scavenging for a grid, if there are no agreed standards universally available. Another issue in this context is time-sensitive data. Some data may have a certain lifetime, meaning its values are only valid during a defined time period. The jobs in a grid application have to reflect this in order to operate with valid data when executing. Especially when using data caching or other replication techniques, it has to be assured that the data used by the jobs is up-to-date, at any given point in time. The order of data processing by the individual jobs, especially the production of input data for subsequent jobs, has to be carefully observed. Depending on the job, the authors Jacob at al. (2003) recommend to consider the following datarelated questions which refer to input as well as output data of the jobs within the grid application: • • • • •
68
Is it reasonable that each job or set of jobs accesses the data via the network? Does it make sense to transport a job or set of jobs to the data location? Is there any data access server (for example, implemented as a federated database) that allows access by a job locally or remotely via the network? Are there time constraints for data transport over the network, for example, to avoid busy hours and transport the data to the jobs in a batch job during off-peak hours? Is there a caching system available on the network to be exploited for serving the same data to several consuming jobs?
Porting Applications to Grids
•
Is the data only available in a unique location for access, or are there replicas that are closer to the executable within the grid?
Data Volume The ability for a grid job to access the data it needs will affect the performance of the application. When the data involved is either a large amount of data or a subset of a very large data set, then moving the data set to the execution node is not always feasible. Some of the considerations as to what is feasible include the volume of the data to be handled, the bandwidth of the network, and logical interdependences on the data between multiple jobs. Data volume issues: In a grid application, transparent access to its input and output data is required. In most cases the relevant data is permanently located on remote locations and the jobs are likely to process local copies. This access to the data results in a network cost and it must be carefully quantified. Data volume and network bandwidth play an important role in determining the scalability of a grid application. Data splitting and separation: Data topology considerations may require the splitting, extraction, or replication of data from data sources involved. There are two general approaches that are suitable for higher scalability in a grid application: Independent tasks per job and a static input file for all jobs. In the case of independent tasks, the application can be split into several jobs that are able to work independently on a disjoint subset of the input data. Each job produces its own output data and the gathering of all of the results of the jobs provides the output result by itself. The scalability of such a solution depends on the time required to transfer input data, and on the processing time to prepare input data and generate the final data result. In this case the input data may be transported to the individual nodes on which its corresponding job is to be run. Preloading of the data might be possible depending on other criteria like timeliness of data or amount of the separated data subsets in relation to the network bandwidth. In the case of static input files, each job repeatedly works on the same static input data, but with different parameters, over a long period of time. The job can work on the same static input data several times but with different parameters, for which it generates differing results. A major improvement for the performance of the grid application may be derived by transferring the input data ahead of time as close as possible to the compute nodes. Other cases of data separation: More unfavorable cases may appear when jobs have dependencies on each other. The application flow may be carefully checked in order to determine the level of parallelism to be reached. The number of jobs that can be run simultaneously without dependences is important in this context. For independent jobs, there needs to be synchronization mechanisms in place to handle the concurrent access to the data. Synchronizing access to one output file: Here all jobs work with common input data and generate their output to be stored in a common data store. The output data generation implies that software is needed to provide synchronization between the jobs. Another way to process this case is to let each job generate individual output files, and then to run a post-processing program to merge all these output files into the final result. A similar case is that each job has its individual input data set, which it can consume. All jobs then produce output data to be stored in a common data set. Like described above, the synchronization of the output for the final result can be done through software designed for the task. Hence, thorough evaluation of the input and output data for jobs in the grid application is needed to properly handle it. Also, one should weigh the available data tools, such as federated databases, a data
69
Porting Applications to Grids
joiner, and related products and technologies, in case the grid application is highly data oriented or the data shows a complex structure.
PORTING AND PROGRAMMING GRID APPLICATIONS Besides taking into account the underlying grid resources and the application’s data handling, as discussed in the previous two paragraphs, another challenge is the porting of the application program itself. In this context, developers and users are facing mainly two different approaches when implementing their application on a grid. Either they port an existing application code on a set of distributed grid resources. Often, in the past, the application previously has been developed and optimized with a specific computer architecture in mind, for example, mainframes or servers, single- or multiple-CPU vector computers, shared- or distributed-memory parallel computers, or loosely coupled distributed systems like workstation clusters, for example. Or developers start from scratch and design and develop a new application program with the grid in mind, often such that the application architecture respectively its inherent numerical algorithms are optimally mapped onto the best-suited (set of) resources in a grid. In both scenarios, the effort of implementing an application can be huge. Therefore, it is important to perform a careful analysis beforehand on: the user requirements for running the application on a grid (e.g. cost, time); on application type (e.g. compute or data intensive); application architecture and algorithms (e.g. explicit, or implicit) and application components and how they interact (e.g. loosely or tightly coupled, or workflows); what is the best way to map the application onto a grid; and which is the best suited grid architecture to run the application in an optimally performing way. Therefore, in the following, we summarize the most popular strategies for porting an existing application to a grid, and for designing and developing a new grid application. Many scientific papers and books deal with the issues of designing, programming, and porting grid applications, and it is difficult to recommend the best suited among them. Here, we mainly follow the books from Ian Foster and Carl Kesselman (1999 & 2004), the IBM Redbook (Jacob, 2003), the SURA Grid Technology Cookbook (SURA, 2007), several research papers on programming models and environments, e.g. Soh (2006), Badia (2003), Karonis (2002), Seymour (2002), Buyya (2000), Venugopal (2004), Luther (2005), Altintas (2004), and Frey (2005), and our own experience at Sun Microsystems and MCNC (Gentzsch, 2004), RENCI (Gentzsch, 2007), D-Grid (Gentzsch, 2008, and Neuroth, 2007), and currently in DEISA-2 (2008).
Grid Programming Models and Environments Our own experience in porting applications to distributed resource environments is very similar to the one from Soh et al. (2006) who present a useful discussion on grid programming models and environments which we briefly summarize in the following. In their paper, they start with differentiating application porting into resource composition and program composition. Resource composition, i.e. matching the application to the grid resources needed, has already been discussed in paragraphs 2 and 3 above. Concerning program composition, there is a wide spectrum of strategies of distributing an application onto the available grid resources. This spectrum ranges from the ideal situation of simply distributing a list of, say, n parameters together with n identical copies of that application program onto the Grid, to the other end of the spectrum where one has to compose or parallelize the program into chunks or components
70
Porting Applications to Grids
that can be distributed to the grid resources for execution. In the latter case, Soh (2006) differentiates between implicit parallelism, where programs are automatically parallelized by the environment, and explicit parallelism which requires the programmer to be responsible for most of the parallelization effort such as task decomposition, mapping tasks to processors and inter-task communication. However, implicit approaches often lead to non-scalable parallel performance, while explicit approaches often are complex and work- and time-consuming. In the following we summarize and update the approaches and methods discussed in detail in Soh (2006): Superscalar (or STARSs), sequential applications composed of tasks are automatically converted into parallel applications where the tasks are executed in different parallel resources. The parallelization takes into account the existing data dependencesbetween the tasks, building a dependence graph. The runtime takes care of the task scheduling and data handling between the different resources, and takes into account the locality of the data between other aspects. There are several implementations available, like GRID Superscalar (GRIDSs) for computational Grids (Badia, 2003), which is also used in production at the MareNostrum supercomputer at the BSC in Barcelona; or Cell Superscalar (CellSs) for the Cell processor (Perez, 2007) and SMP Superscalar (SMPSs) for homogeneous multicores or shared memory machines. Explicit Communication, such as Message Passing and Remote Procedure Call (RPC). A messages passing example is MPICH-G2 (Karonis, 2002), a Grid-enabled implementation of the Message Passing Interface (MPI) which defines standard functions for communication between processes and groups of processes, extended by the Globus Toolkit. An RPC example is GridRPC, an API for Grids (Seymour, 2002), which offers a convenient, high-level abstraction whereby many interactions with a Grid environment can be hidden. Bag of Tasks, which can be easily distributed on grid resources. An example is the Nimrod-G Broker (Buyya, 2000) which is a Grid-aware version of Nimrod, a specialized parametric modeling system. Nimrod uses a simple declarative parametric modeling language and automates the task of formulating, running, monitoring, and aggregating results. Another example is the Gridbus Broker (Venugopal, 2004) that permits users access to heterogeneous Grid resources transparently. Distributed Objects, as in ProActive (2005), a Java based library that provides an API for the creation, execution and management of distributed active objects. Proactive is composed of only standard Java classes and requires no changes to the Java Virtual Machine (JVM) allowing Grid applications to be developed using standard Java code. Distributed Threads, for example Alchemi (Luther, 2005), a Microsoft .NET Grid computing framework, consisting of service-oriented middleware and an application program interface (API). Alchemi features a simple and familiar multithreaded programming model. Grid Workflows. Many Workflow Environments have been developed in recent years for Grids, such as Triana, Taverna, Simdat, P-Grade, and Kepler. Kepler, for example, is a scientific workflow management system along with a set of Application Program Interfaces (APIs) for heterogeneous hierarchical modeling (Altintas, 2004). Kepler provides a modular, activity oriented programming environment, with an intuitive GUI to build complex scientific workflows. Grid Services. An example is the Open Grid Services Architecture (OGSA) (Frey, 2005) which is an ongoing project that aims to enable interoperability between heterogeneous resources by aligning Grid technologies with established Web services technology. The concept of a Grid service is introduced as a Web service that provides a set of well defined interfaces that follow specific conventions. These grid services can be composed into more sophisticated services to meet the needs of users.
71
Porting Applications to Grids
Grid-Enabling Application Programs and Numerical Algorithms In many cases, restructuring (grid-enabling, decomposing, parallelizing) the core algorithm(s) within a single application program doesn’t make sense, especially in the case of a more powerful higher-level grid-enabling strategy. For example, in the case of parameter jobs (see below), many identical copies of the application program together with different data-sets can easily be distributed onto many grid nodes, or where the application program components can be mapped onto a workflow, or where applications (granularity, run time, special dimension, etc.) simply are too small to efficiently run on a grid, and the grid latencies and management overhead become too dominant. In other cases, however, where e.g. just one very long run has to be performed, grid-enabling the application program itself can lead to dramatic performance improvements and, thus, time savings. In an effort to better guide the reader through this complex field, in the following, we will briefly present a few popular application codes and their algorithmic structure and provide recommendations for some meaningful grid-enabling strategies. General Approach. First, we have to make sure that we gain an important benefit form running our application on a grid. And we should start asking a few more general questions, top-down. Has this code been developed in-house, or is it a third-party code, developed elsewhere? Will I submit many jobs (as e.g. in a parameter study), or is the overall application structure a workflow, or is it a single monolithic application code? In case of the latter, are the core algorithms within the application program of explicit or of implicit nature? In many cases, grid-enabling those kinds of applications can be based on experience made in the past with parallelizing them for the moderately or massively parallel systems, see e.g. Fox et al. (1994) and Dongarra et al. (2003). In-house Codes. In case of an application code developed in-house, the source code of this application is often still available, and ideally the code developers are still around. Then, we have the possibility to analyze the structure of the code, its components (subroutines), dependencies, data handling, core algorithms, etc. With older codes, sometimes, this analysis has already been done before, especially for the vector and parallel computer architectures of the 1980ies and 1990ies. Indeed, some of this knowledge can be re-used now for the grid-enabling process, and often only minor adjustments are needed to port such a code to the grid. Third-Party Codes licensed from so-called Independent Software Vendors (ISVs) cannot be gridenabled without the support from these ISVs. Therefore, in this case, we recommend to contact the ISV. In case the ISV receives similar requests from other customers as well, there might be a real chance that the ISV will either provide a grid-enabled code or completely change its sales strategy and sell its software as a service, or develops its own application portal to provide access to the application and the computing resources. But, obviously, this requires patience and is thus not a solution if you are under a time constraint. Parameter Jobs. In science and engineering, often, the application has to run many times: same code, different data. Only a few parameters have to be modified for each individual job, and at the end of the many job runs, the results are analyzed with statistical or stochastic methods, to find a certain optimum. For example, during the design of a new car model, many crash simulations have to be performed, with the aim to find the best-suited material and geometry for a specific part of the wire-frame model of the car. Application Workflows. It is very common in so-called Problem Solving Environments that the application program consists of a set of components or modules which interact with each other. This can be modeled in grid workflow environments which support the design and the execution of the workflow
72
Porting Applications to Grids
representing the application program. Usually, these grid workflow environments contain a middleware layer which maps the application modules onto the different resources in the grid. Many Workflow Environments have been developed in recent years for Grids, such as Triana (2003), Taverna (2008), Simdat (2008), P-Grade (2003), and Kepler (Altintas, 2004). One application which is well suited for such a workflow is climate simulation. Today’s climate codes consist of modules for simulating the weather on the continent with mesoscale meteorology models, and include other modules for taking into account the influence from ocean and ocean currents, snow and ice, sea ice, wind, clouds and precipitation, solar and terrestrial radiation, absorption, emission, and reflection, land surface processes, volcanic gases and particles, and human influences. Interactions happen between all these components, e.g. air-ocean, air-ice, ice-ocean, ocean-land, etc. resulting in a quite complex workflow which can be mapped onto the underlying grid infrastructure. Highly Parallel Applications. Amdahl’s Law states that the scalar portion of a parallel program becomes a dominant factor as processor number increases, leading to a loss in application scalability with growing number of processors. Gustafson (1988) proved that this holds only for fixed problem size, and that in practice, with increasing number of processors, the user increases problem size as well, always trying to solve the largest possible problem on any given number of CPUs. Gustafson demonstrated this on a 1028-processor parallel system, for several applications. For example, he was able to achieve a speed-up factor of over 1000 for a Computational Fluid Dynamics application with 1028 parallel processes on the 1028-processor system. Porting these highly parallel applications to a grid, however, has shown that many of them degrade in performance simply because overhead of communication for message-passing operations (e.g. send and receive) drops from a few microseconds on a tightly-coupled parallel system to a few milliseconds on a (loosely-coupled) workstation cluster or grid. In this case, therefore, we recommend to implement a coarse-grain Domain Decomposition approach, i.e. to dynamically partition the overall computational domain into sub-domains (each consisting of as many parallel processes, volumes, finite elements, as possible), such that each sub-domain completely fits onto the available processors of the corresponding parallel system in the grid. Thus, only moderate performance degradation from the reduced number of inter-system communication can be expected. A prerequisite for this to work successfully is that the subset of selected parallel systems is of homogeneous nature, i.e. architecture and operating system of these parallel systems should be identical. One Grid infrastructure which offers this feature is the Distributed European Infrastructure for Supercomputing Applications (DEISA, 2008), which (among others) provides a homogeneous cluster of parallel AIX machines distributed over several of the 11 European supercomputing centers which are part of DEISA (see also Section 5 in this Chapter). Moderately Parallel Applications. These applications, which have been parallelized in the past, often using Message Passing MPI library functions for the inter-process communication on workstation clusters or on small parallel systems, are well-suited for parallel systems with perhaps a few dozen to a few hundreds of processors, but they won’t scale easily to a large number of parallel processes (and processors). Reasons are a significant scalar portion of the code which can’t run in parallel and/or the relatively high ratio of inter-process communication to computation, resulting in relatively high idle times of the CPUs waiting fore the data. Many commercial codes fall in this category, for example finiteelement codes such as Abaqus, Nastran, or Pamcrash. Here we recommend to check if the main goal is to analyze many similar scenarios with one and the same code but on different data sets, and run as many codes in parallel as possible, on as many moderately parallel sub-systems as possible (this could be virtualized sub-systems on one large supercomputer, for example).
73
Porting Applications to Grids
Explicit vs. Implicit Algorithms. Discrete Analogues of systems of partial differential equations, stemming from numerical methods such as finite difference, finite volume, or finite element discretizations, often result in large sets of explicit or implicit algebraic equations for the unknown discrete variables (e.g. velocity vectors, pressure, temperature). The explicit methods are usually slower (in convergence to the exact solution vector of the algebraic system) than the implicit ones but they are also inherently parallel, because there is no dependence of the solution variables among each other, and therefore there are no recursive algorithms. In case of the more accurate implicit methods, however, solution variables are highly inter-dependent leading to recursive sparse-matrix systems of algebraic equations which cannot easily split (parallelized) into smaller systems. Again, here, we recommend to introduce a Domain Decomposition approach as described in the above section on Highly Parallel Algorithms, and solve an implicit sparse-matrix system within each domain, and bundle sets of ‘neighboring’ domains into super-sets to submit to the (homogeneous) grid. Domain Decomposition. This has been discussed in the paragraphs on Highly Parallel Applications and on Explicit vs. Implicit Algorithms. Job Mix. Last but not lease, one of the most trivial but most widely used scenarios often found in university and research computer centers is the general job mix, stemming from hundreds or thousands of daily users, with hundreds or even thousands of different applications, with varying requirements for computer architecture, data handling, memory and disc space, timing, priority, etc. This scenario is ideal for a grid which is managed by an intelligent Distributed Resource Manager (DRM), for example GridWay (2008) for a global grid, Sun Grid Engine Enterprise Edition (Chaubal, 2003) for an enterprise grid, or the open source Grid Engine (2001) for a departmental grid or a simple cluster. These DRMs are able to equally balance the overall job load across the distributed resource environment and submit the jobs always to the best suited and least loaded resources. This can result in overall resource utilization of 90% and higher.
Applications and Grid Portals Grid portals are an important part of the process of grid-enabling, composing, manipulating, running, and monitoring applications. After all the lower layers of the grid-enabling process have been performed (described in the previous paragraphs), often, the user is still exposed to the many details of the grid services and even has to take care of configuring, composing, provisioning, etc. the application and the services “by hand”. This however can be drastically simplified and mostly hidden from the user through a Grid portal, which is a Web-based portal able to expose Grid services and resources through a browser to allow users remote, ubiquitous, transparent and secure access to grid services (computers, storage, data, applications, etc). The main goal of a Grid portal is to hide the details and complexity of the underlying Grid infrastructure from the user in order to improve usability and utilization of the Grid, greatly simplifying the use of Grid-enabled applications through a user-friendly interface. Grid portals have become popular in research and the industry communities. Using Grid portals, computational and data-intensive applications such as genomics, financial modeling, crash test analysis, oil and gas exploration, and many more, can be provided over the Web as traditional services. Examples of existing scientific application portals are the GEONgrid (2008) and CHRONOS (2004) portals that provide a platform for the Earth Science community to study and understand the complex dynamics of Earth systems; the NEESGrid project (2008) focuses on earthquake engineering research; the BIRN portal (2008) targets biomedical informatics researchers; and the MyGrid portal (2008) provides access
74
Porting Applications to Grids
to bioinformatics tools running on a back-end Grid infrastructure. As it turns out, scientific portals are usually being developed inside specific research projects. As a result they are specialized for specific applications and services satisfying project requirements for that particular research application area. In order to rapidly build customized Grid portals in a flexible and modular way, several more generic toolkits and frameworks have been developed. These frameworks are designed to meet the diverse needs and usage models arising from both research and industry. One of these frameworks is EnginFrame, which simplifies development of highly functional Grid portals exposing computing services that run on a broad range of different computational Grid systems. EnginFrame (Beltrame, 2006) has been adopted by many industrial companies, and by organizations in research and education.
Example: The EnginFrame Portal Environment EnginFrame (2008) is a Web-based portal technology that enables the access and the exploitation of grid-enabled applications and infrastructures. It allows organizations to provide application-oriented computing and data services to both users (via Web browsers) and in-house or ISV applications (via SOAP/WSDL based Web services), thus hiding the complexity of the underlying Grid infrastructure. Within a company or department, an enterprise portal aggregates and consolidates the services and exposes them to the users, through the Web. EnginFrame can be integrated as Web application in a J2EE standard application server or as a portlet in a JSR168 compliant portlet container. As a Grid portal framework, EnginFrame offers a wide range of functionalities to IT developers facing the task to provide application-oriented services to the end users. EnginFrame’s plug-in mechanism allows to easily and dynamically extend its set of functionalities and services. A plug-in is a selfcontained software bundle that encapsulates XML Extensible Markup Language service descriptions, custom layout or XSL Extensible Stylesheet Language and the scripts or executables involved with the services actions. A flexible authentication delegation offers a wide set of pre-configured authentication mechanisms: OS/NIS/PAM, LDAP, Microsoft Active Directory, MyProxy, Globus, etc. It can also be extended throughout the plug-in mechanism. Besides authentication, EnginFrame provides an authorization framework that allows to define groups of users and Access Control Lists (ACLs), and to bind ACLs to resources, services, service parameters and service results. The Web interface of the services provided by the portal can be authorized and thus tailored to the specific users’ roles and access rights. EnginFrame supports a wide variety of compute Grid middleware like LSF, PBS, Sun Grid Engine, Globus, gLite and others. An XML virtualization layer invokes specific middleware commands and translates results, jobs and Grid resource descriptions into a portable XML format called GridML that abstracts from the actual underlying Grid technology. For the GridML, as for the service description XML, the framework provides pre-built XSLs to translate GridML into HTML. EnginFrame data management allows for browsing and handling data on the client side or remotely archived in the Grid and then to host a service working environment in file system areas called spoolers. The EnginFrame architecture is structured into three tiers, Client, Resource, Server. The Client Tier normally consists of the user’s Web browser and provides an easy-to-use interface based on established Web standards like XHTML and JavaScript, and it is independent from the specific software and hardware environment used by the end user. When needed, the client tier also provides integration with desktop virtualization technologies like Citrix Metaframe (ICA), VNC, X, and Nomachine NX. The Resource Tier consists of one or more Agents deployed on the back-end Grid infrastructure whose role is to control
75
Porting Applications to Grids
and provide distributed access to the actual computing resources. The Server Tier consists of a server component that provides resource brokering to manage resource activities in the back-end. The EnginFrame server authenticates and authorizes incoming requests from the Web, and asks an Agent to execute the required actions. Agents can perform different kind of actions that range from the execution of a simple command on the underlying Operating System, to the submission of a job to the Grid. The results of the executed action are gathered by the Agent and sent back to the Server which applies post processing transformations, filters the output according to ACLs and transforms the results into a suitable format according to the nature of the client: HTML for Web browsers and XML in a SOAP message for Web services client applications.
CASE STUDY: APPLICATIONS ON THE DEISA INFRASTRUCTURE As one example, in the following, we will discuss the DEISA Distributed European Infrastructure for Supercomputing Applications. DEISA (2008) is different from many other Grid initiatives which aim at building a general purpose grid infrastructure and therefore have to cope with many (almost) insurmountable barriers such as complexity, resource sharing, crossing administrative (and even national) domains, handling IP and legal issues, dealing with sensitive data, working on interoperability, and facing the issue to expose every little detail of the underlying infrastructure services to the grid application user. DEISA avoids most of these barriers by staying very focused: The main focus of DEISA is to provide the European supercomputer user with a flexible, dynamic, user-friendly supercomputing ecosystem (one could say Supercomputing Cloud, see next paragraph) for easy handling, submitting, and monitoring long-running jobs on the best-suited and least-loaded supercomputer(s) in Europe, trying to avoid the just mentioned barriers. In addition, DEISA offers application-enabling support. For a similar European funded initiative especially focusing on enterprise applications, we refer the reader to the BEinGRID project (2008), which consists of 18 so-called business experiments each dealing with a pilot application that addresses a concrete business case, and is represented by an end-user, a service provider, and a Grid service integrator. Experiments come from key business sectors such as multimedia, financial, engineering, chemistry, gaming, environmental science, and logistics and so on, based on different Grid middleware solutions, see (BEinGRID, 2008).
The DEISA Project DEISA is the Distributed European Initiative for Supercomputing Applications, funded by the EU in Framework Program 6 (DEISA1, 2004 – 2008) and Framework Program 7 (DEISA2, 2008 – 2011). The DEISA Consortium consists of 11 partners, MPG-RZG (Germany, consortium lead), BSC (Spain), CINECA (Italy), CSC (Finland), ECMWF (UK), EPCC (UK), FZJ (Germany), LRS (Germany), IDRIS (France), LRZ (Germany), and SARA (Netherlands), and 3 asociated partners KTH (Sweden), CSCS (Switzerland), and JSCC (Russia). DEISA develops and supports a distributed high performance computing infrastructure and a collaborative environment for capability computing and data management. The resulting infrastructure enables the operation of a powerful Supercomputing Grid built on top of national supercomputing services, facilitating Europe’s ability to undertake world-leading computational science research. DEISA is certainly instrumental for advancing computational sciences in scientific and industrial disciplines within
76
Porting Applications to Grids
Europe and is paving the way towards the deployment of a cooperative European HPC ecosystem. The existing infrastructure is based on the coupling of eleven leading national supercomputing centers, using dedicated network interconnections (currently 10 GBs) of GÉANT2 and the NRENs. DEISA2 develops activities and services relevant for applications enabling, operation, and technologies, as these are indispensable for the effective support of computational sciences in the area of supercomputing. The service provisioning model is extended from one that supports a single project (in DEISA1) to one supporting Virtual European Communities (now in DEISA2). Collaborative activities will be carried out with new European and other international initiatives. Of strategic importance is the cooperation with the PRACE (2008) initiative which is preparing for the installation of a limited number of leadership-class Tier-0 supercomputers in Europe.
The DEISA Infrastructure Services The essential services to operate the infrastructure and support its efficient usage are organized in the three Service Activities Operations, Technologies, and Applications: Operations refer to operating the infrastructure including all existing services, adopting approved new services from the Technologies activity, and advancing the operation of the DEISA HPC infrastructure to a turnkey solution for the future European HPC ecosystem by improving the operational model and integrating new sites. Technologies cover monitoring of technologies in use in the project, identifying and selecting technologies of relevance for the project, evaluating technologies for pre-production deployment, and planning and designing specific sub-infrastructures to upgrade existing services or deliver new ones based on approved technologies. User-friendly access to the DEISA Supercomputing Grid is provided by DEISA Services for Heterogeneous management Layer (DESHL, 2008) and the UNiforme Interface for COmputing Resources (UNICORE, 2008). Applications cover the areas applications enabling and extreme computing projects, environment and user related application support, and benchmarking. Applications enabling focuses on enhancing scientific applications from the DEISA Extreme Computing Initiative (DECI), Virtual Communities and EU projects. Environment and user related application support addresses the maintenance and improvement of the DEISA application environment and interfaces, and DEISA-wide user support in the applications area. Benchmarking refers to the provision and maintenance of a European Benchmark Suite for supercomputers. In DEISA2, two Joint Research Activities (JRA) complement the portfolio of service activities. JRA1 (Integrated DEISA Development Environment) aims at an integrated environment for scientific application development, based on a software infrastructure for tools integration, which provides a common user interface across multiple computing platforms. JRA2 (Enhancing Scalability) aims at the enabling of supercomputer applications for the efficient exploitation of current and future supercomputers, to cope with a production infrastructure characterized by an aggressive parallelism on heterogeneous HPC architectures at a European scale.
DECI – DEISA Extreme Computing Initiative for Supercomputing Applications The DEISA Extreme Computing Initiative (DECI, 2008) has been launched in May 2005 by the DEISA Consortium, as a way to enhance its impact on science and technology. The main purpose
77
Porting Applications to Grids
of this initiative is to enable a number of “grand challenge” applications in all areas of science and technology. These leading, ground breaking applications must deal with complex, demanding and innovative simulations that would not be possible without the DEISA infrastructure, and which benefit from the exceptional resources provided by the Consortium. The DEISA applications are expected to have requirements that cannot be fulfilled by the national services alone. In DEISA2, the single-project oriented activities (DECI) will be qualitatively extended towards persistent support of Virtual Science Communities. This extended initiative will benefit from and build on the experiences of the DEISA scientific Joint Research Activities where selected computing needs of various scientific communities and a pilot industry partner were addressed. Examples of structured science communities with which close relationships are planned to be established are EFDA and the European climate community. DEISA2 will provide a computational platform for them, offering integration via distributed services and web applications, as well as managing data repositories.
Applications Adapted to the DEISA Grid Infrastructure In the following, we describe examples of application profiles and use cases that are well-suited for the DEISA supercomputing Grid, and that can benefit from the computational resources made available by the DECI Extreme Computing Initiative. International collaboration involving scientific teams that access the nodes of the AIX super-cluster in different countries, can benefit from a common data repository and a unique, integrated programming and production environment (via common global file systems). Imagine, for example, that team A in France and team B in Germany dispose of allocated resources at IDRIS in Paris and FZJ in Juelich, respectively. They can benefit from a shared directory in the distributed super-cluster, and for all practical purposes it looks as if they were accessing a single supercomputer. Extreme computing demands of a challenging project requiring a dominant fraction of a single supercomputer. Rather than spreading a huge, tightly coupled parallel application on two or more supercomputers, DEISA can organize the management of its distributed resource pool such that it is possible to allocate a substantial fraction of a single supercomputer to this project which is obviously more efficient that splitting the application and distributing it over several supercomputers. Workflow applications involving at least two different HPC platforms. Workflow applications are simulations where several independent codes act successively on a stream of data, the output of one code being the input of the next one in the chain. Often, this chain of computations is more efficient if each code runs on the best-suited HPC platform (e.g. scalar, vector, or parallel supercomputers) where it develops the best performance. Support of these applications via UNICORE (2008) which allows treating the whole simulation chain as a single job is one of the strengths of the DEISA Grid. Coupled applications involving more than one platform. In some cases, it does make sense to spread a complex application over several computing platforms. This is the case of multi-physics, multi-scale application codes involving several computing modules each dealing with one particular physical phenomenon, and which only need to exchange a moderate amount of data in real time. DEISA has already developed a few applications of this kind, and is ready to consider new ones, providing substantial support to their development. This activity is more prospective, because systematic production runs of coupled applications require a co-allocation service which is currently being implemented.
78
Porting Applications to Grids
APPLICATIONS IN THE CLOUD With increasing demand for higher performance, efficiency, productivity, agility, and lower cost, since several years, Information Communication Technologies, ICT, are dramatically changing from static silos with manually managing resources and applications, towards dynamic virtual environments with automated and shared services, i.e. from silo-oriented to service-oriented architectures. With sciences and businesses turning global and competitive, applications, products and services becoming more complex, and research and development teams being distributed, ICT is in transition again. Global challenges require global approaches: on the horizon, so-called virtual organizations and partner grids will provide the necessary communication and collaboration platform, with grid portals for secure access to resources, applications, data, and collaboratories. One component which will certainly foster this next-generation scenario is Cloud Computing, as recently offered by companies like Sun (2006) Network.com, IBM (2008), Amazon (2007) Elastic Compute Cloud, and Google (2008) App Engine, Google Group (2008), and CloudCamp (2008), and many more in the near future. Clouds will become important dynamic components of research and enterprise grids, adding a new ‘external’ dimension of flexibility to them by enhancing their ‘home’ resource capacity whenever needed, on demand. Existing businesses will use them for their peak demands and for new projects, service providers will host their applications on them and provide Software as a Service (SaaS), start-ups will integrate them in their offerings without the need to buy resources upfront, and setting up new Web 2.0 communities will become very easy. To Cloud-enable applications will follow similar strategies as with grid-enabling, as discussed in the previous paragraphs. Similarly challenging as with Grids, though, are the cultural, mental, legal, and political aspects in the Cloud context. Building trust and reputation among the users and the providers will help in some scenarios. But it is currently difficult to imagine that users may easily entrust their corporate core assets and sensitive data to Cloud service providers. Today (in October 2008) the status of Clouds seems to be similar to the status of Grids in the early 2000s: a few simple and well-suited application scenarios run on Clouds, but by far most of the more complex and demanding applications in research and enterprises will face many barriers on Clouds which still have to be removed, one by one. One example of an early innovative Cloud system came from Sun when it truly built its SunGrid (2005) from scratch, based on the vision that the network is the computer. As with other early technologies in the past, Sun paid a high price for being first and doing all the experiments and the evangelization, but their reputation as an innovator is here to stay. Its successor, Sun Network.com (2008), is very popular among its few die-hard clients. This is because of an easy-to use technology (Grid Engine, Jini, JavaSpaces), but it’s especially because of their innovative early users, such as CDO2 (2008), and because of the instant support users get from the Sun team. A similar promising example in the future might be the DEISA Distributed European Infrastructure for Supercomputing Applications, with its DECI – DEISA Extreme Computing Initiative. Why is DECI currently so successful in offering millions of supercomputing cycles to the European e-Science community and helping scientists gain new scientific insights? Several reasons, in my opinion: because DEISA has a very targeted focus on specific (long-running) supercomputing applications and most of the applications just run on one – best-suited - system; because of its user-friendly access - through technology like DESHL (2008) and UNICORE (2008); because of staying away from those more ambitious general-purpose Grid efforts; because of its coordinating function which leaves the consortium partners (the European supercomputer centers) fully independent; and – similar to network.com – because of
79
Porting Applications to Grids
ATASKF (DECI (2008), the application task force, application experts who help the users with porting their applications to the DEISA infrastructure. If all this is here to stay, and the (currently funded) activities will be taken over by the individual supercomputer centers, DEISA will have a good chance to exist for a long time, even after the funding will run dry. And then, we might end up with a DEISA Cloud which will become an (external) HPC node within your Grid application workflow. With this sea-change ahead of us, there will be a continuous strategic importance for sciences and businesses to support the work of the Open Grid Forum (OGF, 2008). Because only standards will enable building e-infrastructures and grid-enabled applications easily from different components and to transition towards an agile platform for federated services. Standards, developed in OGF, guarantee – upfront - interoperation of components best suited for your applications, and thus reducing dependency from proprietary building blocks, keeping cost under control, and increasing research and business flexibility.
CONCLUSION: 10 RULES FOR BUILDING A SUSTAINABLE GRID FOR SUSTAINABLE APPLICATIONS Sustainable grid-enabled applications require sustainable grid infrastructures. It doesn’t make any sense, for example, in a three-year funded Grid project, to develop or port a complex application to the Grid which will shut down after the project ends. We have to make sure that we are able to build sustainable grid infrastructures which will last for a long time. Therefore, in the following, the author offers ‘his’ 10 rules for building a sustainable grid, available also from the OGF Thought Leadership (2008). These rules are derived from mainly four sources: my research on major grid projects published in a RENCI report (Gentzsch, 2007a), the e-IRG Workshop on “A Sustainable Grid Infrastructure for Europe” in (Gentzsch, 2007b), the 2nd International Workshop on Campus and Community Grids at OGF20 in Manchester (McGinnis, 2007), and my personal experience with coordinating the German D-Grid Initiative (D-Grid, 2008). The rules presented here are mainly non-technical, because I believe most of the challenges in building and operating a grid are in the form of cultural, legal and regulatory barriers. Rule 1: Identify your specific benefits. Your first thought should be about your users and your organization. What’s in it for them? Identify the benefits which fit best: transparent access to and better utilization of resources; almost infinite compute and storage capacity; flexibility, adaptability and automation through dynamic and concerted interoperation of networked resources; cost reduction through utility model; shorter time-to-market because of more simulations at the same time on the grid. Grid technology helps to adjust an enterprise’s IT architecture to real business requirements (and not vice versa). For example, global companies will be able to decompose their highly complex processes into modular components of a workflow which can be distributed around the globe such that on-demand availability and access to suitable workforce and resources are assured, productivity increased, and cost reduced. Application of grid technology in these processes, guarantees seamless integration of and communication among all distributed components and provides transparent and secure access to sensitive company information and other proprietary assets, world-wide. Grid computing is especially of great benefit for those research and business groups which cannot afford expensive IT resources . It enables engineers to remotely access any IT resource as a utility, to simulate any process and any product (and product life cycle) before it is built, resulting in higher quality, increased functionality, and cost and risk reduction.
80
Porting Applications to Grids
Rule 2: Evangelize your decision makers first. They give you the money and authority for your grid project. The more they know about the project and the more they believe in it (and in you) the more money and time you will get, and the easier becomes your task to lead and motivate your team and to get things done. Present a business case (current deficiencies, specific benefits of the grid (see Rule #1), how much will it cost and how much will it return, etc. They might also have to modify existing policies, top down, to make it easier for users (and providers) to cope with the challenges of and to accept and use the new services. For example, why would a researcher (or a department in an enterprise) stop buying computers when money continues to be allocated for buying it? This policy should be changed to support a utility model instead of an ownership model. If you are building a national grid, for example, convincing your government to modify its research funding model is a tough task. Rule 3: Don’t re-invent wheels. In the early grid days, many grid projects tried to develop the whole software stack themselves: from the middleware layer, to the software tools, to grid-enabling the applications, to the portal and Web layer…and got troubled by the next technology change. Today, so many grid technologies, products and projects exist that you want to start looking for similar projects, select your favorite (successful) ones which fit best your users’ needs, and ‘copy’ what they have built, and that will be your prototype. Then, you might still have some time and money left to optimize it so it fully matches the requirements of your users. Consider, however, that all grids are different. For example, research grids are mainly about sharing (e.g. sharing resources, knowledge, data), commercial enterprise grids are about cost and revenue (e.g. TCO, ROI, productivity). Therefore, if your community is academic, look for academic use cases, if it’s commercial, look for commercial use cases in your respective business field. Rule 4: KISS (Keep It Simple and Stupid). It took your users years to get acquainted with their current working environment and tools. Ideally, you won’t change that. Try hard to stick with what they have and how they do things. Plan for an incremental approach and lots of time listening and talking. Social effects dominate in grids. Join forces with the system people to change/modify mainly the lower layers of the architecture. Your users are your customers, they are king. Differentiate between two groups of users: the end users who are designing and developing the products (or the research results) which account for all the earnings of your company (or reputation and therefore funding for your research institute), and the system experts who are eager to support the end users with the best possible services. Therefore, you can only succeed if you demonstrate a handful of clear benefits to these two user groups. Rule 5: Evolution, not revolution. As the saying goes: “never change a running system”... We all hate changes in our daily lives, except when we are sure that things will drastically improving. Your users and their applications deeply depend on a reliable infrastructure. So, whenever you have to change especially the user layer, only change it in small steps and in large time cycles. And, start with enhancing existing service models moderately, and test suitable utility models first as pilots. And, very important, part of your business plan has to be an excellent training and communications strategy. Rule 6: Establish a governance structure. Define clear responsibilities and dependencies for specific tasks, duties and people during and after the project. An advisory board should include your representatives of your end-users as well as application and system experts. In case of more complex projects, e.g. consisting of an integration project and several application or community projects, an efficient management board should lead and steer coordination and collaboration among the projects and the working groups. The management board (Steering Committee) should consist of leaders of the sub-projects. Regular face-to-face meetings are very important. Rule 7: Money, money, money. Don’t have unrealistic expectations that grid computing will save you
81
Porting Applications to Grids
money initially.. In their early stage, grid projects need enough funding to get over the early-adopter phase into a mature state with a rock-solid grid infrastructure such that other user communities can join easily. In research grids, for example, we estimate this funding phase currently to be in the order of 3-5 years, with more funding in the beginning for the grid infrastructure, and later more funding for the application communities. In larger (e.g. global) research grids, funding must cover Teams or Centers of Excellence, for building, managing and operating the grid infrastructure, and for middleware tools, application support, and training. Also, today’s funding models in research and education are often project based and thus not ready for a utilitarian approach where resource usage is based on a pay-as-you- go approach. Old funding models first have to be adjusted accordingly before a utility model can be introduced successfully. For example, today’s existing government funding models are often counter-productive when establishing new and efficient forms of utility services (see Rule #2). In the long run, grid computing will save you money through a much more efficient, flexible and productive infrastructure. Rule 8: Secure some funding for after the end of the project. Continuity especially for maintenance and support are extremely important for the sustainability of your grid infrastructure. Make sure at the beginning of your project that additional funding will be available after the end of the project, to guarantee service and support and continuous improvement and adjustment of the infrastructure. Rule 9: Try not to grid-enable your applications in the first place. Adjusting your application to changing technologies costs a lot of effort and money, and takes a lot of your precious time. Did you macro-assemble, vectorize, multitask, parallelize, or multithread your application yourself in the past? Then, grid-enabling that code is relatively easy, ay we have seen in this article. But doing this from scratch is not what the user should do. Better to use the money to buy (lease, rent, subscribe to) software as a service or to hire a few consultants who grid-enable your application and/or (even better) help you enable your grid architecture to dynamically cope with the applications and user requirements (instead vice versa). Today, in grids, we are looking more at chunks of independent jobs, (or chunks of transactions). And we let our schedulers and brokers decide how to distribute these chunks onto the best-suited and least-loaded servers in the grid, or let the servers decide themselves to share the chunks with their neighbors automatically whenever they become overloaded. Rule 10: Adopt a ‘human’ business model. Don’t invent new business models. This usually increases the risk for failure. Learn from the business models we have with our other service infrastructures: water, gas, telephony, electricity, mass transportation, the Internet, and the World Wide Web. Despite this wide variety of areas, there is only a handful of successful business models: on one end of the spectrum, you pay the total price, and the whole thing is yours. Or you pay only a share of it, but pay the other share on a per usage basis. Or you rent everything, and pay chunks back on a regular basis, like a subscription fee or leasing. Or you pay just for what you use. Sometimes, however, there are ‘hidden’ or secondary applications. For example, electrical power alone doesn’t help. It’s only useful if it generates something, e.g. light, or heat, or cold, etc. And this infrastructure is what creates a whole new industry of new appliances: light bulbs, heaters, refrigerators, etc. Back to grids: providing the right (transparent) infrastructure (services) and the right (simple) business model will most certainly create a new set of services which most probably will improve our quality of life in the future.
82
Porting Applications to Grids
REFERENCES Altintas, I., Berkley, C., Jaeger, E., Jones, M., Ludascher, B., & Mock, S. (2004). Kepler: an extensible system for design and execution of scientific workflows. In Proceedings of the 16th International Conference on Scientific and Statistical Database Management (SSDBM), Santorini Island, Greece. Amazon Elastic Compute Cloud (2007). Retrieved from www.amazon.com/ec2 Badia, R. M., Labarta, J. S., Sirvent, R. L., Perez, J. M., Cela, J. M., & Grima, R. (2003). Programming grid applications with GRID superscalar. Journal of Grid Computing, 1, 151–170. doi:10.1023/ B:GRID.0000024072.93701.f3 Baker, S. (2007). Google and the wisdom of clouds. Business Week, Dec. 13. Retrieved from www. businessweek.com/magazine/content/07_52/b4064048925836.htm BEinGRID. (2008). Business experiments in grids. Retrieved from www.beingrid.com Beltrame, F., Maggi, P., Melato, M., Molinari, E., Sisto, R., & Torterolo, L. (2006, February 2-3). SRB Data grid and compute grid integration via the enginframe grid portal. In Proceedings of the 1st SRB Workshop, San Diego, CA. Retrieved from www.sdsc.edu/srb/Workshop/SRB-handout-v2.pdf BIRN. (2008). Biomedical informatics research network. Retrieved from www.nbirn.net/index.shtm Buyya, R., Abramson, D., & Giddy, J. (2000). Nimrod/G: An architecture for a resource management and scheduling system in a global computational grid. In Proceedings of the 4th International Conference on High Performance Computing in the Asia-Pacific Region. Retrieved from www.csse.monash. edu.au/~davida/nimrod/nimrodg.htm CDO2. (2008). CDOSheet for pricing and risk analysis. Retrieved from www.cdo2.com Chaubal, Ch. (2003). Sun grid engine, enterprise edition—Software configuration guidelines and use cases. Sun Blueprints, Retrieved from www.sun.com/blueprints/0703/817-3179.pdf CloudCamp. (2008). Retrived from http://www.cloudcamp.com/ D-Grid (2008). Retrieved from www.d-grid.de/index.php?id=1&L=1 DECI. (2008). DEISA extreme computing initiative. Retrieved from www.deisa.eu/science/deci DEISA. (2008). Distributed European infrastructure for supercomputing applications. Retrieved from www.deisa.eu DESHL. (2008). DEISA services for heterogeneous management layer. http://forge.nesc.ac.uk/projects/ deisa-jra7/ Dongarra, J., Foster, I., Fox, G., Gropp, W., Kennedy, K., Torczon, L., & White, A. (2003). Sourcebook of parallel computing. San Francisco: Morgan Kaufmann Publishers. EnginFrame. (2008). Grid and cloud portal. Retrieved from www.nice-italy.com Foster, I. (2000). Internet computing and the emerging grid. Nature. Retrieved from www.nature.com/ nature/webmatters/grid/grid.html
83
Porting Applications to Grids
Foster, I. (2002). What is the Grid? A three point checklist. Retrieved from http://www-fp.mcs.anl. gov/~foster/Articles/WhatIsTheGrid.pdf Foster, I. Kesselman, & C., Tuecke, S. (2002). The anatomy of the Grid: Enabling scalable virtual organizations. Retrieved from www.globus.org/alliance/publications/papers/anatomy.pdf Foster, I., & Kesselman, C. (Eds.). (1999). The Grid: Blueprint for a new computing infrastructure. San Francisco: Morgan Kaufmann Publishers. Foster, I., & Kesselman, C. (Eds.). (2004). The Grid 2: Blueprint for a new computing infrastructure. San Francisco: Morgan Kaufmann Publishers. Fox, G., Williams, R., & Messina, P. (1994). Parallel computing works! San Francisco: Morgan Kaufmann Publishers. Frey, J., Mori, T., Nick, J., Smith, C., Snelling, D., Srinivasan, L., & Unger, J. (2005). The open grid services architecture, Version 1.0. Retrieved from www.ggf.org/ggf_areas_architecture.htm GAT. (2005). Grid application toolkit. www.gridlab.org/WorkPackages/wp-1/ Gentzsch, W. (2002). Response to Ian Foster’s “What is the Grid?” GRIDtoday, August 5. Retrieved from www.gridtoday.com/02/0805/100191.html Gentzsch, W. (2004). Grid computing adoption in research and industry. In A. Abbas (Ed.), Grid computing: A practical guide to technology and applications (pp. 309 – 340). Florence, KY: Charles River Media Publishers. Gentzsch, W. (2004). Enterprise resource management: Applications in research and industry. In I. Foster & C. Kesselman (Eds.), The Grid 2: Blueprint for a new computing infrastructure (pp. 157 – 166). San Francisco: Morgan Kaufmann Publishers. Gentzsch, W. (2007a). Grid initiatives: Lessons learned and recommendations. RENCI Report. Retrieved from www.renci.org/publications/reports.php Gentzsch, W. (Ed.). (2007b). A sustainable Grid infrastructure for Europe, Executive Summary of the e-IRG Open Workshop on e-Infrastructures, Heidelberg, Germany. Retrieved from www.e-irg.org/ meetings/2007-DE/workshop.html Gentzsch (2008). Top 10 rules for building a sustainable Grid. In Grid thought leadership series. Retrieved from www.ogf.org/TLS/?id=1 GEONgrid. (2008). Retrieved from www.geongrid.org Goodale, T., Jha, S., Kaiser, H., Kielmann, T., Kleijer, P., Merzky, A., et al. (2008). A simple API for Grid applications (SAGA). Grid Forum Document GFD.90. Open Grid Forum. Retrieved from www. ogf.org/documents/GFD.90.pdf Google (2008). Google App Engine. Retrieved from http://code.google.com/appengine/ Google Groups. (2008). Cloud computing. Retrieved from http://groups.google.ca/group/cloud-computing
84
Porting Applications to Grids
Grid Engine. (2001). Open source project. Retrieved from http://gridengine.sunsource.net/ GridSphere (2008). Retrieved from www.gridsphere.org/gridsphere/gridsphere GridWay. (2008). Metascheduling technologies for the grid. Retrieved from www.gridway.org/ Gustafson, J. (1988). Reevaluating Amdahl’s law. Communications of the ACM, 31, 532–533. doi:10.1145/42411.42415 Jacob, B., Ferreira, L., Bieberstein, N., Gilzean, C., Girard, J.-Y., Strachowski, R., & Yu, S. (2003). Enabling applications for Grid computing with Globus. IBM Redbook. Retrieved from www.redbooks. ibm.com/abstracts/sg246936.html?Open Jha, S., Kaiser, H., El Khamra, Y., & Weidner, O. (2007, Dec. 10-13). Design and implementation of network performance aware applications using SAGA and Cactus. 3rd IEEE Conference on eScience and Grid Computing, (pp. 143- 150). Bangalore, India. Karonis, N. T., Toonen, B., & Foster, I. (2003). MPICH-G2: A Grid-enabled implementation of the message passing interface. [JPDC]. Journal of Parallel and Distributed Computing, 63, 551–563. doi:10.1016/S0743-7315(03)00002-9 Lee, C. (2003). Grid programming models: Current tools, issues and directions. In G. F. Fran Berman, T. Hey, (Eds.), Grid computing (pp. 555–578). New York: Wiley Press. Luther, A., Buyya, R., Ranjan, R., & Venugopal, S. (2005). Peer-to-peer grid computing and a. NETbased alchemi framework. high performance computing: Paradigm and Infrastructure. In M. Guo, (Ed.). New York: Wiley Press. Retrieved from www.alchemi.net McGinnis, L., Wallom, D., & Gentzsch, W. (Eds.). (2007). 2nd International Workshop on Campus and Community Grids. retrieved from http://forge.gridforum.org/sf/go/doc14617?nav=1 MyGrid. (2008). Retrieved from www.mygrid.org.uk NEESgrid. (2008). Retrieved from www.nees.org/ Neuroth, H., Kerzel, M., & Gentzsch, W. (Eds.). (2007). German Grid Initiative D-Grid. Göttingen, Germany: Universitätsverlag Göttingen Publishers. Retrieved from www.d-grid.de/index.php?id=4&L=1 OGF. (2008). Open Grid Forum. Retrieved from www.ogf.org P-GRADE. (2003). Parallel grid run-time and application development environment. Retrieved from www.lpds.sztaki.hu/pgrade/ Perez, J.M., Bellens, P., Badia, R.M., & Labarta, J. (2007, August). CellSs: Programming the Cell/ B.E. made easier. IBM Journal of R&D, 51(5). Portal, C. H. R. O. N. O. S. (2004). Retrieved from http://portal.chronos.org/gridsphere/gridsphere PRACE. (2008). Partnership for advanced computing in Europe. Retrieved from www.prace-project. eu/
85
Porting Applications to Grids
Proactive (2005). Proactive manual REVISED 2.2., Proactive, INRIA. Retrieved from http://www-sop. inria.fr/oasis/Proactive/ Saara Väärtö, S. (Ed.). (2008). Advancing science in Europe. DEISA – Distributed European Infrastructure for Supercomputing Applications. EU FP6 Project. Retrieved from www.deisa.eu/press/DEISAAdvancingScienceInEurope.pdf SAGA. (2006). SAGA implementation home page Retrieved from http://fortytwo.cct.lsu. edu:8000/SAGA Seymour, K., Nakada, H., Matsuoka, S., Dongarra, J., Lee, C., & Casanova, H. (2002). Overview of GridRPC: A remote procedure call API for Grid computing. In Proceedings of the Third International Workshop on Grid Computing, Baltimore, MD (LNCS 2536, pp. 274–278). Berlin: Springer. SIMDAT. (2008). Grids for industrial product development. Retrieved from www.scai.fraunhofer.de/ about_simdat.html Soh, H., Shazia Haque, S., Liao, W., & Buyya, R. (2006). Grid programming models and environments. In Yuan-Shun Dai, et al. (Eds.) Advanced parallel and distributed computing (pp. 141–173). Hauppauge, NY: Nova Science Publishers. Sun Network. com (2008). Retrieved from www.network.com/ SunGrid. (2005). Sun utility computing. Retrieved from www.sun.com/service/sungrid/ SURA Southeastern Universities Research Association. (2007). The Grid technology cookbook: Programming concepts and challenges. Retrieved from www.sura.org/cookbook/gtcb/ TAVERNA. (2008). The Taverna Workbench 1.7. Retrieved from http://taverna.sourceforge.net/ TRIANA. (2003). The Triana Project. Retrieved from www.trianacode.org/ UNICORE. (2008). UNiform Interface to COmputing Resources. Retrieved from www.unicore.eu/ Venugopal, S., Buyya, R., & Winton, L. (2004). A grid service broker for scheduling distributed dataoriented applications on global grids. Proceedings of the 2nd workshop on Middleware for grid computing, Toronto, Canada, (pp. 75–80). Retrieved from www.Gridbus.org/broker
KEY TERMS AND DEFINITIONS Clouds Computing: Computing paradigm focusing on provisioning of metered services related to the use of hardware, software platforms, and applications, billed on a pay-per-use base, and pushed by vendors such as Amazon, Google, Microsoft, Salesforce, Sun, and others. Accordingly, there are many different (but similar) definitions (as with Grid Computing). DECI: The purpose of the DEISA Extreme Computing Initiative (DECI) is to enhance the impact of the DEISA research infrastructure on leading European science and technology. DECI identifies, enables, deploys and operates “flagship” applications in selected areas of science and technology. These leading, ground breaking applications must deal with complex, demanding, innovative simulations that
86
Porting Applications to Grids
would not be possible without the DEISA infrastructure, and which would benefit from the exceptional resources of the Consortium. DEISA: The Distributed European Infrastructure for Supercomputing Applications is a consortium of leading national supercomputing centres that currently deploys and operates a persistent, production quality, distributed supercomputing environment with continental scope. The purpose of this EU funded research infrastructure is to enable scientific discovery across a broad spectrum of science and technology, by enhancing and reinforcing European capabilities in the area of high performance computing. This becomes possible through a deep integration of existing national high-end platforms, tightly coupled by a dedicated network and supported by innovative system and grid software. Grid: A service for sharing computer power and data storage capacity over the Internet, unlike the Web which is a service just for sharing information over the Internet. The Grid goes well beyond simple communication between computers, and aims ultimately to turn the global network of computers into one vast computational resource. Today, the Grid is a “work in progress”, with the underlying technology still in a prototype phase, and being developed by hundreds of researchers and software engineers around the world. Open Grid Forum: The Open Grid Forum is a community of users, developers, and vendors leading the global standardisation effort for grid computing. OGF accelerates grid adoption to enable business value and scientific discovery by providing an open forum for grid innovation and developing open standards for grid software interoperability. The work of OGF is carried out through community-initiated working groups, which develop standards and specifications in cooperation with other leading standards organisations, software vendors, and users. The OGF community consists of thousands of individuals in industry and research, representing over 400 organisations in more than 50 countries. Globus Toolkit: A software toolkit designed by the Globus Alliance to provide a set of tools for Grid Computing middleware based on standard grid APIs. Its latest development version, GT4, is based on standards currently being drafted by the Open Grid Forum. Grid Engine: An open source batch-queuing and workload management system. Grid Engine is typically used on a compute farm or compute cluster and is responsible for accepting, scheduling, dispatching, and managing the remote execution of large numbers of standalone, parallel or interactive user jobs. It also manages and schedules the allocation of distributed resources such as processors, memory, disk space, and software licenses. Grid Portal: A Grid Portal provides a single secure web interface for end-users and administrators to computational resources (computing, storage, network, data, applications) and other services, while hiding the complexity of the underlying hardware and software of the distributed computing environment. An example is the EnginFrame cluster, grid, and cloud portal which for example in DEISA serves as the portal for the Life Science community. OGSA: The Open Grid Services Architecture, describes an architecture for a service-oriented grid computing environment for business and scientific use, developed within the Open Grid Forum. OGSA is based on several Web service technologies, notably WSDL and SOAP. Briefly, OGSA is a distributed interaction and computing architecture based around services, assuring interoperability on heterogeneous systems so that different types of resources can communicate and share information. OGSA has been described as a refinement of the emerging Web Services architecture, specifically designed to support Grid requirements. Web Service: A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-process able format (specifically WSDL).
87
Porting Applications to Grids
Other systems interact with the Web service in a manner prescribed by its description using SOAPmessages, typically conveyed using HTTP with an XML serialisation in conjunction with other Webrelated standards. UNICORE: The Uniform Interface to Computing Resources offers a ready-to-run Grid system including client and server software. UNICORE makes distributed computing and data resources available in a seamless and secure way in intranets and the internet. The UNICORE project created software that allows users to submit jobs to remote high performance computing resources without having to learn details of the target operating system, data storage conventions and techniques, or administrative policies and procedures at the target site. Virtual Organization: A group of people with similar interest that primarily interact via communication media such as newsletters, telephone, email, online social networks etc. rather than face to face, for social, professional, educational or other purposes. In Grid Computing, a VO is a group who shares the same computing resources.
ENDNOTE 1
88
Another version of this chapter was published in the International Journal of Grid and High Performance Computing, Volume 1, Issue 1, edited by Emmanuel Udoh, pp. 55-76, copyright 2009 by IGI Publishing, formerly known as Idea Group Publishing (an imprint of IGI Global).
89
Chapter 5
Benchmarking Grid Applications for Performance and Scalability Predictions Radu Prodan University of Innsbruck, Austria Farrukh Nadeem University of Innsbruck, Austria Thomas Fahringer University of Innsbruck, Austria
ABSTRACT Application benchmarks can play a key role in analyzing and predicting the performance and scalability of Grid applications, serve as an evaluation of the fitness of a collection of Grid resources for running a specific application or class of applications (Tsouloupas & Dikaiakos, 2007), and help in implementing performance-aware resource allocation policies of real time job schedulers. However, application benchmarks have been largely ignored due to diversified types of applications, multi-constrained executions, dynamic Grid behavior, and heavy computational costs. To remedy these, the authors present an approach taken by the ASKALON Grid environment that computes application benchmarks considering variations in the problem size of the application and machine size of the Grid site. Their system dynamically controls the number of benchmarking experiments for individual applications and manages the execution of these experiments on different Grid sites. They present experimental results of our method for three real-world applications in the Austrian Grid environment.
INTRODUCTION Grid infrastructures provide an opportunity to the scientific and business communities to exploit the powers of heterogeneous resources in multiple administrative domains under a single umbrella (Foster & Kesselman, The Grid: Blueprint for a Future Computing Infrastructure, 2004). Proper characterization DOI: 10.4018/978-1-60566-661-7.ch005
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Benchmarking Grid Applications for Performance and Scalability Predictions
of Grid resources is of key importance in effective mapping and scheduling of the jobs in order to minimize execution time of complex workflows and utilize maximum power of these resources. Benchmarking has been used for many years to characterize a large variety of resources ranging from CPU architectures to file systems, databases, parallel systems, internet infrastructures, or middleware (Dikaiakos, 2007). There have always been issues regarding optimized mapping of jobs to the Grid resources on the basis of available benchmarks (Tirado-Ramos, Tsouloupas, Dikaiakos, & Sloot, 2005). Existing Grid benchmarks (or their combinations) do not suffice to measure/predict application performance and scalability, and give a quantitative comparison of different Grid sites for individual applications while taking into effect variations in the problem size. In addition, there are no integration mechanisms and common units available for existing benchmarks to make meaningful inferences about the performance and scalability of individual Grid applications on different Grid sites. Application benchmarking on the Grid can provide a basis for users and Grid middleware services (like meta-schedulers (Berman, et al., 2005) and resource brokers (Raman, Livny, & Solomon, 1999)) for optimized mapping of jobs to the Grid resources by serving as an evaluation of fitness to compare different computing resources in the Grid. The performance results obtained from real application benchmarking are much more useful for scheduling these applications on a highly distributed Grid infrastructure than the regular resource information provided by the standard Grid information services (Tirado-Ramos, Tsouloupas, Dikaiakos, & Sloot, 2005) (Czajkowski, Fitzgerald, Foster, & Kesselman, 2001). Application benchmarks are also helpful in predicting the performance and scalability of Grid applications, studying the effects of variations in application performance for different problem sizes, and gaining insights into the properties of computing nodes architectures. However, the complexity, heterogeneity, and the dynamic nature of Grids raise serious questions about the overall realization and applicability of application benchmarking. Moreover, diversified types of applications, multi-constrained executions, and heavy computational costs make the problem even harder. Above all, mechanizing the whole process of controlling and managing benchmarking experiments and making benchmarks available to users and Grid services in an easy and flexible fashion makes the problem more challenging. To overcome this situation, we present a three layered Grid application benchmarking system that produces benchmarks for Grid applications taking into effect the variations in problem size and machine size of the Grid sites. Our system provides the necessary support for conducting controlled and reproducible experiments, for computing performance benchmarks accurately, and for comparing and interpreting benchmarking results in the context of application performance and scalability predictions. It takes the specifications of executables, set of problem sizes, pre-execution requirements and the set of available Grid sites in an input in XML format. These XML specifications, along with the available resources are parsed to generate jobs to be submitted to different Grid sites. At first, the system completes pre-experiment requirements like the topological order of activities in a workflow, and then runs the experiments according to the experimental strategy. The benchmarks are computed from experimental results and archived in a repository for later use. Performance and scalability prediction and analysis from the benchmarks are available through a graphical user interface and Web Service Resource Framework (WSRF) (Banks, 2006) service interfaces. We do not require complex integration/analysis of measurements, or new metrics for interpretation of benchmarking results. Among our considerations for the design of Grid application benchmarks were conciseness, portability, easy computation and adaptability for different Grid users/services. We have implemented a
90
Benchmarking Grid Applications for Performance and Scalability Predictions
prototype of the proposed system as a WSRF service in the context of the ASKALON Grid application development and computing environment (Fahringer, et al., 2006). The rest of the chapter is organized as follows. The next section presents the Grid resource, application, and execution models that serve as foundation for our work. Then, we summarize the requirements of a prediction system, followed by a detailed architecture design. Afterwards we present our experimental design method for benchmarking and prediction of Grid applications. Experimental results that validate our work on real-world applications in a real Grid environment are presented in the second half of this chapter, followed by a related work summary and an outlook into the future work. The last section concludes the chapter.
BACKGROUND In this section we first review the relevant related work in the area of Grid application benchmarking, and then define the general Grid resource, application, and execution models that represent the foundation for our benchmarking and prediction work.
Related Work There have been several significant efforts that targeted benchmarking of individual Grid resources such as (Hockney & Berry, 1994) (Bailey, et al., 1991) (Dixit, 1991) (Dongarra, Luszczek, & Petitet, 2003). The discussion presented in (Van der Wijngaart & Frumkin, 2004) shows that the configuration, administration, and analysis of NAS Grid Benchmarks requires an extensive manual effort like other benchmarks. Moreover, these benchmarks lack some integration mechanism needed to make meaningful inferences about the performance of different Grid applications. A couple of comprehensive tools like (Tsouloupas & Dikaiakos, 2007) are also available for benchmarking a wide range of Grid resources. These provide easy means of archiving and publishing of results. Likewise, GrenchMark (Iosup & Epema, GRENCHMARKIosup & Epema, GRENCHMARK: A Framework for Analyzing, Testing, and Comparing Grids, 2006) is a framework for analyzing, testing, and comparing Grid settings. Its main focus is the generation and submission of synthetic Grid workloads. In contrast, our work focuses on single application benchmarks which are extensively supported. Individual benchmarks have been successfully used for resource allocation (Afgan, Velusamy, & Bangalore, 2005) (Jarvis & Nudd, 2005) and application scheduling (Heymann, Fernandez, Senar, & Salt, 2003). A good work for resource selection is presented in (Jarvis & Nudd, 2005) by building models from resource performance benchmarks and application performance details. Authors in (Afgan, Velusamy, & Bangalore, 2005) present resource filter, resource ranker and resource MakeMatch on the basis of benchmarks, and user provided information. Though this work provides good accuracy, it requires much user intervention during the whole process. Moreover, these benchmarks do not support cross-platform performance translations of different Grid applications while considering variations in problem sizes. A similar work has been presented in (Tirado-Ramos, Tsouloupas, Dikaiakos, & Sloot, 2005). The authors present a tool for resource selection for different applications while considering variations in performance due to different machine sizes. Importance of application-specific benchmarks is
91
Benchmarking Grid Applications for Performance and Scalability Predictions
also described by (Seltzer, Krinsky, & Smith, 1999). In this work, the authors present three different methodologies to benchmark Grid applications by modeling application and Grid site information and require much manual intervention. The distinctive part of our work is that we focus on controlling and specifying the total number of experiments needed for benchmarking process. Our proposed benchmarks are flexible regarding variations in machine size as well as problem sizes required for real-time scheduling and application performance prediction. Moreover, we support a semi-automatic benchmarking process. The cross-platform interoperability of our benchmarks allows trade-off analysis and translation of performance information between different platforms.
Grid Resource Model We consider the Grid as an aggregation of heterogeneous Grid sites. A Grid site consists of a number of compute and storage systems that share same local security, network, and resource management policies. Our experimental Grid environment comprises homogeneous parallel computers within a Grid site, including cache coherent Non-Uniform Memory Architectures (ccNUMA), Clusters of Workstations (COW), and Networks of desktop Workstations (NOW). Each parallel computer is utilized as a single computing resource using a local resource management system such as Sun Grid Engine (SGE), Portable Batch System (PBS) or its Maui and Torque derivatives. To simplify the presentation and without losing any generality, we assume in the remainder of the paper that a Grid site is a homogeneous parallel computer. A heterogeneous Grid consists of an aggregation of homogeneous sites.
Grid Workflow Model The workflow model based on loosely-coupled coordination of atomic activities has emerged as one of the most attractive paradigms in the Grid community for programming Grid applications. Despite this, most existing Grid application development environments provide the application developer with a nontransparent Grid. Commonly, application developers are explicitly involved in tedious tasks such as selecting software components deployed on specific sites, mapping applications onto the Grid, or selecting appropriate computers for their applications. In this section we propose an abstract Grid workflow model that is completely decoupled from the underlying Grid technologies such as Globus toolkit (Foster & Kesselman, Globus: A Metacomputing Infrastructure Toolkit, 1997) or Web services ((W3C), World Wide Web Consortium). We define a workflow as a Directed Acyclic Graph (DAG): W = (Nodes, C-Edges, D-edges, IN-ports, OUT-ports), where Nodes is the set of activities, C-edges = ∪(A1,A2)∈Nodes (A1, A2) is the set of control flow dependencies, D-edges = ∪(A1,A2,D-port)∈Nodes (A1, A2, D-port) is the set of data flow dependencies, IN-ports is the set of workflow input data ports, and OUT-ports is the set of output data ports. An activity A∈Nodes is a mapping from a set of input data ports IN-portsA to a set of output data ports OUT-portsA: A: IN-portsA → OUT-portsA.
92
Benchmarking Grid Applications for Performance and Scalability Predictions
A data port D-port ∈IN-portsA × OUT-portsA is an association between a unique identifier (within the workflow representation) and a well-defined activity type: D-port = (identifier, type). The type of a data port is instantiated by the type system supported by the underlying implementation language, e.g. the XML schema. The most important data type in our experience that shall be supported for Grid workflows is file alongside other basic types such as integer, float, or string. An activity N∈Nodes can be of two kinds: 1. 2.
Computational activity or atomic activity represents an atomic unit of computation such as a legacy sequential or parallel application; Composite activity is a generic term for an activity that aggregates multiple (atomic and composite) activities according to one of the following four patterns: a. parallel loop activity allows the user to express large-scale workflows consisting of hundreds or thousands of atomic activities in a compact manner; b. sequential loop activity defines repetitive computations with possibly unknown number of iterations (e.g. dynamic convergence criteria that depend on the runtime output data port values computed within one iteration); c. conditional activity models if and switch-like statements that activate one from its multiple successor activities based on the evaluation of a boolean condition; d. workflow activity is introduced for modularity and reuse purposes, and is recursively defined according to this definition.
In the remainder of this paper we will use the terms activity and application interchangeably. In this paper we only deal with the benchmarking and prediction of computational activities, while data transfer prediction has been addressed in related work such as (Wolski, 2003). We designed and implemented our approach within the ASKALON Grid application development and computing environment that allows the specification of workflows according to this model at two levels of abstraction (see Figure 1): • •
graphical, based on the standard Unified Modeling Language (UML); XML-based using the Abstract Grid Workflow Language (AGWL) which can be automatically generated from the graphical UML representation.
Grid Execution Model The XML-based AGWL representation of a workflow represents the input to the ASKALON WSRFbased (Banks, 2006) middleware services for execution on the Grid (see Figure 1). To support this requirement transparently, a set of sophisticated services whose functionality is not directly exposed to the end-user is essential: •
•
Resource Manager (Siddiqui, Villazon, Hoffer, & Fahringer, 2005) is responsible for negotiation, reservation, allocation of resources, and automatic deployment of services required executing Grid applications. In combination with AGWL, the Resource Manager shields the user from the low-level Grid infrastructure; Scheduler (Wieczorek, Prodan, & Fahringer, 2005) determines effective mappings of single or
93
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 1. The ASKALON Grid application development and computing environment architecture
•
• • •
multiple workflows onto the Grid using graph-based heuristics and single or bi-criteria optimization algorithms such as dynamic programming, game theory, or genetic algorithms; Performance prediction supports the scheduler with information about the expected execution time of activities on individual Grid resources. The design and implementation of this service is the scope of the this paper; Enactment Engine (Duan, Prodan, & Fahringer, 2006) targets scalable, reliable and fault-tolerant execution of workflows; Data repository is a relational database used by the Enactment Engine to log detailed workflow execution events required for post-mortem analysis and visualization; Performance analysis (Prodan & Fahringer, 2008) supports automatic instrumentation and bottleneck detection through online monitoring of a broad set of high-level workflow overheads (over 50), systematically organized in a hierarchy comprising job management, control of parallelism, communication, load imbalance, external load, or other middleware overheads.
PREDICTION REqUIREMENTS The performance of an application is dependent upon a number of inter-related parameters at different levels of Grid infrastructure (e.g. Grid site, computing nodes, processor architecture, memory hierarchy, I/O, storage node, network (LAN or WAN), network topology), as shown in Figure 2 adapted from (Dikaiakos, 2007). Practically it is almost impossible to characterize the effects of all these individual components to shape the overall performance behavior of different Grid applications. Even benchmarks of different resource components cannot be put together to describe application performance because application properties must also be taken into effect (Hockney & Berry, 1994). In such a case, application performance benchmarks with some mechanism of application performance translation across the
94
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 2. Factors affecting Grid application performance
heterogeneous Grid sites can help to describe its performance in the Grid. Application benchmarks include effects of different resource components, in particular their combinational varying effects specific to individual applications. Our solution to performance prediction is therefore to benchmark scientific applications according to a well-thought experimental design strategy across heterogeneous Grid sites. These benchmarks are flexible to application problem size and number of processors (machine size) and are thus called soft benchmarks. More specifically there is a need for benchmarks, which: • • • • • • •
Represent the performance of Grid application on different Grid sites; Incorporate the individual effects of different Grid resources specific to different applications (like memory, caching, etc.); Can be used for performance and scalability predictions of the application; Are portable to different platforms (De Roure & Surridge, 2003); Are flexible regarding variations in problem and machine sizes; Support fast and simplified computation and management; Are comprehensively understandable and usable by different users and services.
On the other hand, it is also necessary to address the high cost of Grid benchmarking administration, benchmarking computation, and analysis which requires a comprehensive system with a visualization and analysis component.
95
Benchmarking Grid Applications for Performance and Scalability Predictions
ARCHITECTURE DESIGN The design of our prediction framework illustrated in Figure 3 consists of a set of tools organized in three layers that perform and facilitate the benchmarking process (the benchmarking experiments, computation, and storage of results) in a flexible way, and later publish the results and perform analysis. In the first layer, the application details for benchmarking experiments are specified in an XMLbased language, which is parsed by a small compiler that produces the job descriptions in the Globus Resource Specification Language (RSL) (Foster & Kesselman, Globus: A Metacomputing Infrastructure Toolkit, 1997). Later, to these job descriptions are added resource specifications on which these jobs are to be launched, to produce final jobs used for executing the benchmarks experiments. In this layer, the total number of benchmarking experiments for individual applications is controlled with respect to different parameters. In layer 2, the Experiment Execution Engine executes the benchmark experiments on available Grid sites provided by the Resource Manager (Siddiqui, Villazon, Hoffer, & Fahringer, 2005). A Grid site is considered at both micro-level (the individual Grid nodes), as well as macro-level (the entire parallel computer) by taking machine size as a variable in the benchmark measurements. Such application benchmarks therefore incorporate the variations in application performance associated to different problem and machine sizes.
Figure 3. The prediction framework architecture
96
Benchmarking Grid Applications for Performance and Scalability Predictions
The monitoring component watches the execution of the benchmarking experiments and alerts the Orchestrator component in layer 3 to collect the data and coordinate the start-up of the Benchmarks Computation component to compute the benchmarks. The Archive component stores this information in the benchmarks repository for future use. The Benchmarks Visualization Browser publishes the benchmarks in a graphical user interface for user analysis, and Information Service component is an interface to other services.
ExPERIMENTAL DESIGN To support the automatic application execution time prediction, benchmarking experiments need to be made against some experimental design and the generated data be archived automatically for later use. Specifically in our work, the general purpose of the experimental design phase is to set a strategy for generation and execution of a minimum number of benchmarking experiments for an application to support its performance prediction later on. Among others, our key objectives for this phase are to: • • • •
Reduce/minimize training phase time; MMinimize/eliminate the heavy modeling requirements after the training phase; Develop and maintain the efficient scalability of experimental design with respect to the Grid size; Make it generalizable to a wide range of applications on heterogeneous Grid-sites.
To address these objectives, we design our experimental design in the light of guidelines given by Montgomery (Montgomery, 2004): 1.
2. 3. 4.
5.
Recognition of statement of problem: We describe our problem statement as to obtain maximum execution time information of the application at different problem sizes on all heterogeneous Grid sites with different possible machine sizes in minimum number of the experiments; Selection of response variables: In our work the response variable is the execution time of the application; Choice of factors, levels, and ranges: The factors affecting the response variable are the problem size of the application, the Grid size, and the machine size of one parallel computer; Choice/formulation of experimental design: In our experimental design strategy, we minimize first the combinations of Grid size with problem size, and then the combinations of Grid size with machine size. By minimizing the combinations of Grid size with problem size, we minimize the number of experiments against different problem sizes across the heterogeneous Grid sites. Similarly, by minimizing the Grid size combinations with the machine size factor, we minimize number of experiments against different problem sizes across different number of processors. We designed this to eliminate the need of next two steps presented by Montgomery et. al. called statistical analysis and modeling, and conclusions, to minimize the serving costs on the fly; Performing of experiments: We address performing of experiments under automatic training phase as described later in Section 0.
97
Benchmarking Grid Applications for Performance and Scalability Predictions
Experiment Specification To describe application specifications we created a small language called Grid Application Description Language (GADL). A GADL definition specifies the application to be executed, its exact paths retrieved from the Resource Manager, the problem size ranges, and pre-requisites of execution (e.g. predecessor activities within a workflow, environment variables), if any. More precisely, every GADL instance is described by: •
Application name with a set of problems sizes given either as enumerations or as value ranges using a start: end: step pattern:
<parameter> •
Resource manager (Siddiqui, Villazon, Hoffer, & Fahringer, 2005) URI used to retrieve the available Grid sites and location of the application executables implementing the activity types:
•
A set of pre-requisites, comprising the activities which must be finished before the execution (of some components of) the application:
<prerequisites> •
A set of input files required for executing the application:
•
98
An executable needed to change the problem size in some peculiar input files characteristic to scientific applications:
Benchmarking Grid Applications for Performance and Scalability Predictions
<probsizechange> <probsizechange/>
Training Experiments The training or benchmarking phase for an application consists of the experiment executions for different selections of problem and machine sizes on different Grid sites to obtain the corresponding execution times referred as training set or historical data. Automatic performance prediction based on such historical data needs enough amounts of data present in data repository in order to deliverable accurate results. In general, there is a tradeoff between the number of experiment conducted and the accuracy of the prediction. The historical data needs to be generated for every new application ported onto the Grid and/or for every new machine (different from existing machines) added to the Grid. Conducting automatic benchmarking for application execution time predictions on the Grid is a complex problem due to variety of the factors involved. More formally, the automatic training phase benchmarking comprises: •
A set of A activities of different activity types belonging to a workflow W = (Nodes, C-edges, D-edges, IN-ports, OUT-ports); A set of distributed heterogeneous Grid sites; A set of Grid sites or homogeneous parallel computers; A set PA of different workflow problem sizes every workflow activity type A.
• • •
The total number of experiments N produced by this parameter set is: N =
å
ANodes
|site| ö÷ æ PA × ççç å å m ÷÷, çè site Grid m =1 ÷ø
where |PA| denotes the number of problem sizes in the set PA (or the set cardinality) and |sites| the number of processors in a Grid site. The cardinality of Nodes, PA, site, as well as the number of Grid sites and CPU types have a significant effect on the number of experiments and, therefore on the overall duration of the automatic training phase. The goal is to compute a set of experiments such that N is minimized and the prediction accuracy is maximized.
Performance Sharing and Translation Computing the full cross product of the parameters involved in the benchmarking process may lead to a huge number of experiments that cannot be executed exhaustively (or is not necessary). Therefore, controlling the number of experiments is of key importance in the efficiency of the whole benchmarking process. Our focus is to reduce the total number of benchmarking experiments and to maximize the utility of benchmarking results. To reduce the experimental space, we introduce a Performance Sharing and Translation (PST) mechanism based on several multi-parameter performance relativity properties, experimentally observed for
99
Benchmarking Grid Applications for Performance and Scalability Predictions
our case study applications. We normalize the execution times against that of a reference problem size selected by default as the largest problem size to take in effect of inter process communication in the set of problem sizes specified by the user. The normalization mechanism not only makes the performance of different machines comparable, but also provides a basis for translating different performance values across different Grid sites. The normalization of values is based on the observation that for many computeintensive applications, and in particular the embarrassingly pilot parallel applications that scale linearly with the machine and problem sizes and that drive our experimental work, the normalized execution times for different problem and machine sizes are the same on all the Grid sites with 90% accuracy. This allows cross-platform interoperability. For example, the normalized execution on a Grid site g for a certain problem size and machine size will be equal to that of another Grid site h. We define in the following sections the inter- and intra-platform performance relativity properties.
Inter-Platform PST Inter-platform PST specifies that the performance behavior Tg(A,p) of an application A for a problem size p relative to another problem size q on a Grid site g is the same as that of the same problem sizes on another Grid site h: Tg (A, p) Tg (A, q )
»
Th (A, p) Th (A, q )
.
This phenomenon is based on the fact that rate of change in execution time of an application across different problem sizes is preserved on different Grid sites, i.e. the rate of change in execution time of an application A for the problem size p (the target problem size) with respect to another problem size q (the reference problem size) on Grid site g is equal to the rate of change in execution time for the problem size p with respect to the problem size q on Grid site h: DTg (A, p) DTg (A, q )
»
DTh (A, p) DTh (A, q )
.
Intra-Platform PST Similarly, intra-platform PST specifies that the performance behavior of an embarrassingly parallel application A on a Grid site g for a machine size m relative to another machine size n for a problem size p is similar to that for another problem size q: Tg (A, p, m ) Tg (A, p, n )
»
Tg (A, q, m ) Tg (A, q, n )
.
This phenomenon is based on the fact that rate of change in execution time of an application across different problem sizes is preserved for different machine sizes, i.e. the rate of change in execution time of an application for the problem size p and machine size m on Grid site g with respect to that for
100
Benchmarking Grid Applications for Performance and Scalability Predictions
machine size n will be equal to the rate of change in execution time for the problem size q and machine size m with respect to that for a machine size n on the same Grid site: DTg (A, p, m ) DTg (A, p, n )
»
DTg (A, q, m ) DTg (A, q, n )
.
Similarly, the rate of change in executions time of the application across different machine sizes is also preserved for different problem sizes: DTg (A, p, m ) DTg (A, q, m )
»
DTg (A, p, n ) DTg (A, q, n )
.
We use this phenomenon to share execution times for scalability within one Grid site. The accuracy of inter- and intra-platform similarity of normalized behaviors does not depend upon the selection of reference point for embarrassingly parallel applications. However, for parallel applications exploiting inter-process communications during their executions, this accuracy increases as the reference point gets closer to the target point. Usually, the closer the reference point, the greater the similarity (of interprocess communication) it encompasses. Thus, the accuracy increases as the reference problem size gets closer to the target problem size in case of inter-platform PST, respectively the reference problem and machine sizes get closer to the target problem and machine sizes in case of intra-platform PST. More formally, for inter-platform PST: éT (A, p) T (A, p) ù ú = 0, lim êê g - h ú q ® p T (A, q ) T A q ( , ) êë g úû h and similarly for intra-platform PST: éT (A, p, m ) T (A, q, m ) ù ú = 0. lim êê g - g ú n ®m T (A, p, n ) T A q n ( , , ) êë g úû g For normalization from the minimum training set only, we select the maximum problem size (in normal practice of user of the application) and maximum machine size as reference point, to incorporate the maximum effects of inter-process communications in the normalization. The distance between the target point and the reference point for inter- and intra-platform PST on one Grid site is calculated respectively as: 2 ïìï 2 ïï (T (p) - T (q )) + (p - q ) , d =í 2 ïï 2 ïïî (T (m ) - T (n )) + (m - n ) ,
for nearest problem size; for nearest machine size.
101
Benchmarking Grid Applications for Performance and Scalability Predictions
Reduced Experiment Set Our methodology of reducing the number of benchmarking experiments is to enable sharing of the benchmarking information across the Grid sites, as we explained in Section 0. The performance ratios of different Grid sites are different for different applications and they also vary for different problem and machine sizes. First of all, for each application we make one experiment for the reference problem size on each of the non-identical Grid sites. Afterwards, we make a full factorial design of benchmarking experiments on the “fastest” (in terms of processor speed) available Grid site considering the problem and machine size as parameters for that application. We select the largest problem size as the reference problem size whose benchmarks are used to share information across the Grid sites. In the next prediction phase, the process of normalization helps in completing the benchmarks computation for all the Grid sites. For scalability analysis and prediction, one benchmark experiment for each of different machine sizes is also made for the reference problem size. By means of inter-platform PST, the total number of experiments reduces for an activity A with PA problem sizes on a Grid with G sites and an average of M different machine sizes per site from PA ∙ G ∙ M to PA ∙ M + G − 1 and for single parallel computers from PA ∙ M to PA + M − 1. By introducing intraplatform PST, we reduce total number of experiments for parallel machines as Grid sites further to a linear complexity of PA + (M − 1) + (G − 1 Later, we employ prediction mechanism to derive performance values for the problem and machine size combinations that were not effectively benchmarked. We argue that this reduction in the number of performed benchmarks is a reasonable trade-off between duration of the benchmarking process and accuracy. In Section 5, we show experimentally that predictions based on our approach are within 90% accuracy. A similar or better accuracy can be achieved with either more benchmarks, or by using analytical modeling techniques. However, both these alternatives are time-consuming. In addition, analytical modeling requires a separate model and expert knowledge for each new type of application. With current Grid environments hosting hundreds to thousands of different applications (Iosup & Epema, Build-and-Test Workloads for Grid Middleware: Problem, Analysis, and Applications, 2007), analytical modeling for individual application performance and scalability (which requires manual efforts) is impractical, whereas, benchmarking requires only one generic setup.
Experiment Execution Once the set of experiments has been computed, the next phase towards prediction is to execute them according to the experimental design strategy. We employ the opportunistic load balancing algorithm (Schwiegelshohn & Yahyapour, 2000) for scheduling benchmarking experiments in the Grid. The algorithm for automatically conducting benchmarking experiments is shown in Figure 4. We schedule the benchmarking experiments for each workflow activity type in topological order. For every activity type, we make one experiment on every Grid site for one reference problem size and one sequential machine size, which we use later on in the normalization process. Afterwards, we perform the full factorial design of experiments for one processor as machine size. Finally, for scalability predictions we make one experiment for each of the different machine sizes for the reference problem size on the fastest available Grid site. Jobs within one Grid site are submitted in parallel to the local queuing system that executes them according to the local system administration policies.
102
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 4. The automatic application benchmarking algorithm algorithm benchmark_scheduling; input: W = (Nodes, C-edges, D-edges, IN-ports, OUT-ports); Set of problem sizes: PA, A Nodes; Set of Grid sites; output: TS = execution time set; TS = ; for A Nodes pred(A) Nodes p = reference problem size of A (p PA); for site Grid do in parallel Tsite(A, p) = time(execution of A on site for reference problem size p); TS = TS Tsite(A, p); end for; site = the idle Grid site with the fastest processor CPU; for r PA do in parallel Tsite(A, r, n) = time(execution of A on site for problem size r on n reference processors); TS = TS Tsite(A, r, n); end for; for m = 1 to |site| do in parallel Tsite(A, p, m) = time(execution of A on site for problem size p with machine size m); TS = TS Tsite(A, p, m); end for; Nodes = Nodes – A; end for; return TS; end algorithm.
The algorithm returns the execution times of these experiments which are then archived and later used by Benchmarks Computation component to calculate the benchmarks (see Figure 3).
Background Load Sometimes the background load, that is, the applications run by external users, severely affects the performance of some (or even all) the applications in the system, especially on ccNUMA SMP parallel computers. This happens mostly when several applications contend for the same network or processor shares, or when resource utilization is very high and the resource manager is ineffective (Arpaci-Dusseau, Arpaci-Dusseau, Vahdat, Liu, Anderson, & Patterson, 1995). However, our benchmarking procedure does not take into account the background load, at least for the moment. The reason is threefold. First, our goal is to quantify the best achievable performance of an application on a Grid platform without the contention generated by additional users. Work in (Arpaci-Dusseau, Arpaci-Dusseau, Vahdat, Liu, Anderson, & Patterson, 1995) helps quantifying the ratio between the maximum achievable performance and the performance achieved in practice. Second, work in hotspot or symbiotic scheduling (Snavely & Weinberg, 2006) helps scheduling applications with overlapping resource requirements such that the overlap is minimized. Third, while mechanisms for ensuring the background load on the resources have been proposed (Mohamed & Epema, 2005), a better understanding of the structure and of the impact of the background load is needed. We plan to investigate aspects of this problem in future work.
103
Benchmarking Grid Applications for Performance and Scalability Predictions
Performance and Scalability Predictions The benchmarks are computed from the results of experiments and archived in a data repository for future references. This is done in a manner that facilitates the comparisons between the benchmarks for different Grid sites, problem sizes, and machine sizes, along with the performance and scalability predictions. Benchmarks can be browsed through a graphical user interface (see Figure 5) for application performance and scalability predictions for different problem sizes on different Grid sites. In this section we explain how the benchmarks are used for performance and scalability predictions and Grid site comparisons. The performance of an application A can be predicted for any problem size p on any Grid site g from another Grid site h (for which execution time for problem size p exists) from the benchmarks using the normalization method, as follows: Tg (A, p) =
Th (A, p) Th (A, q )
× Tg (A, q ).
Figure 5. Graphical user interface for application benchmarks and predictions
104
Benchmarking Grid Applications for Performance and Scalability Predictions
where Tg(A, p) represents the execution time of an activity A, for a problem size p, on a Grid site g. Similarly, for scalability analysis and prediction taking machine size as a parameter, the performance of the parallel applications for different number of CPUs can be predicted from the benchmarks as follows: Tg (A, p, m ) =
Tg (A, q, m ) Tg (A, q, n )
× Tg (A, p, n ).
where Tg(A, p, m) represents execution time of an application for problem size p on a Grid site g for a machine size m. For execution time and scalability predictions, normalization is done based on execution time for the closest set of parameters (problem size and machine size). At the start, this is made based on the only common set of parameters in the benchmark repository and later, if some other performance values are available (after adding some experimental values from real runs), calculated based on the closer performance value, as it increases accuracy in the cross platform performance and scalability predictions. For our prediction results we obtained a minimum accuracy of 90% from our proposed number of experiments as we will demonstrate in Section 0.
Grid Site Comparisons Our training benchmarks help facilitating the comparisons of applications’ performance for different values of problem and machine sizes on different Grid sites, as the second key use. This can guide the Grid site selection policies for real time schedulers, resource brokers and different Grid users. Furthermore, these comparisons provide application developers with information about the systems capabilities in terms of application performance, so that they can develop and tune their applications for high-quality implementations.
ExPERIMENTS We have conducted experiments to validate our experimental design method in a heterogeneous subset of the Austrian Grid environment summarized in Table 1.
Workflow Applications We used three real-world workflow applications to validate our method: WIEN2k, MeteoAG, and Invmod, which we describe in the next subsections.
WIEN2k WIEN2k (Schwarz, Blaha, & Madsen, 2002) is a program package for performing electronic structure calculations of solids using density functional theory based on the full potential (linearized) augmented
105
Benchmarking Grid Applications for Performance and Scalability Predictions
Table 1. The Austrian Grid testbed Site Name
Architecture
No. CPUs
Processor Architecture
Gigahertz
RAM [megabytes]
Location
altix1.jku
ccNUMA, SGI Altix 3000
64
Itanium 2
1.6
14000
Linz
altix1.uibk
ccNUMA, SGI Altix 350
16
Itanium 2
1.6
16000
Innsbruck
schafberg
ccNUMA, SGI Altix 350
16
Itanium 2
1.6
14000
Salzburg
agrid1
NOW, Fast Ethernet
20
Pentium 4
1.8
1800
Innsbruck
hydra
COW, Fast Ethernet
16
AMD Athlon
2.0
1600
Linz
hc-ma
NOW, Fast Ethernet
16
AMD Opteron 2.2
2.2
4000
Innsbruck
zid-cc
NOW, Fast Ethernet
22
Intel Xeon
2.2
2000
Innsbruck
karwendel
COW, Infiniband
80
AMD Opteron
2.4
16000
Innsbruck
Figure 6. Simplified WIEN2k workflow representation
plane wave ((L)APW) and local orbital (lo) method. We first ported the application onto the Grid by splitting the monolithic code into several course grain activity types coordinated in a workflow as illustrated in Figure 6. The LAPW1 and LAPW2 activities can be solved in parallel by a fixed number of so called k-points. A final activity called Converged applied on several output files tests whether the problem convergence criterion is fulfilled. The number of sequential loop iterations is statically unknown.
106
Benchmarking Grid Applications for Performance and Scalability Predictions
MeteoAG We designed MeteoAG (Schüller, Qin, Nadeem, Prodan, Fahringer, & Mayr, 2006) as a Grid workflow application for meteorological simulations based on the RAMS (Cotton, et al., 2003) numerical atmospheric model. The simulations produce spatial and temporal fields of heavy precipitation cases over the western part of Austria to resolve most alpine watersheds and thunderstorms. A database of reanalyzed heavy precipitation cases is generated in order to study various aspects of objective analysis algorithms for rain gauge networks and the impact of weather radar on the analysis. Figure 7 illustrates the workflow structure in which a large set of simulation cases modeled as a parallel loop. For each simulation, another nested parallel loop is executed with a different so called akmin parameter value. For each individual akmin value, the activities rams makevfile, rams init, revu compare and raver are processed sequentially. Based on the results of the raver activity, a conditional
Figure 7. The simplified MeteoAG workflow
107
Benchmarking Grid Applications for Performance and Scalability Predictions
activity decides whether the activity rams_hist or the parallel loop pforTimeStep (in which the activity revu_dump is enclosed as iteration) are executed.
Invmod Invmod is a hydrological application designed at the University of Innsbruck for calibration of parameters of the WaSiM tool developed at the Swiss Federal Institute of Technology Zurich. Invmod uses the Levenberg-Marquardt algorithm to minimize the least squares of the differences between the measured and the simulated runoff for a determined time period. We re-engineered the monolithic Invmod application into a Grid-enabled scientific workflow consisting of two levels of parallelism as depicted Figure 8: • •
Each iteration of the outermost parallel loop called random run performs a local search optimization starting from an arbitrarily chosen initial solution; Alternative local changes are examined separately for each calibrated parameter, which is done in parallel in the inner nested parallel loop
Figure 8. The simplified Invmod workflow
108
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 9. Experiment reduction with problem, machine, and Grid sizes
The number of sequential loop iterations is variable and depends on the actual convergence of the optimization process. However, it is usually equal to the input maximum iteration number.
Experiment Set Reduction We analyzed the scalability of our experimental design strategy by varying the problem size of our applications from 10 to 200 for fixed values of the remaining factors: ten Grid sites with machine size 20 and 50 single processor machines. We observed a reduction in the total number of experiments from 96% to 99%, as shown in Figure 9. A reduction from 77% to 97% in the total number of experiments was observed when we varied the machine size from one to 80, for fixed factors of 10 parallel machines, 50 single processor Grid sites and problem size of five. From another perspective, we observed that the total number of experiments increased from 7% to 9% when the Grid size was increased from 15 to 155, for the fixed factors of five parallel machines with machine size of 10 and problem size 10. We observed an overall reduction of 78% to 99% when we varied all factors simultaneously: five parallel machines with machine size from 1 to 80, single processor Grid sites from 10 to 95, and problem size from 10 to 95.
Normalized Benchmarks Due to space limitations, we report results on benchmarking one activity from each of the three previously introduced workflows: LAPW1 from WIEN2k, rams_hist from MeteoAG, and wasim_b2c from Invmod. The training benchmarks for the LAPW1 activity type of the WIEN2k workflow on different Grid sites of the Austrian Grid are shown in Figure 10. We made a total of 45 benchmark experiments for
109
Benchmarking Grid Applications for Performance and Scalability Predictions
41 different problem sizes on 5 different Grid sites. The total execution time of our reduced LAPW1 benchmarking phase was 4203.24 seconds, while the total full factorial set would need 5.6 times longer (23614.8 seconds). We repeated every experiment for five times and took their average to reduce the anomalies in the computations due to external factors. For LAPW1, we took the execution time of the problem size 9.0 as the base performance value for normalization. The similar benchmarks curves (for different values of problem size) on different machines show the realization of normalized performance behavior of the Grid benchmarks across heterogeneous platforms. Performance and scalability benchmarks for different number of CPUs for the rams_hist activity type of the MeteoAG workflow on zid-cc and hc-ma Grid sites are shown in Figure 11 and Figure 12, respectively. A total of 30 benchmarking experiments were made for 19 problem sizes and 12 machine sizes on zid-cc, and 32 experiments for 19 problem sizes and 14 machine sizes on hc-ma. In these experiments, we have used a machine size of one for normalization. The identical scalability curves demonstrate the realization of normalized performance behavior of application benchmarks with respect to problem and machine size on one platform. We observed similar results for the wasim_b2c activity of Invmod for different problem sizes on different Grid sites, as showed in Figure 13. Here, the reduced training phase took 2190.62 seconds, while the full factorial set would need about 10711.5 seconds (4.8 times longer).
Grid Site Comparison A comparison of different Grid sites for LAPW1 and wasim_b2c is shown in Figure 14 and Figure 15, respectively. The scalability comparison for MeteoAG for different problem sizes on two different platforms, 32 bit zid-cc and 64 bit hc-ma, is shown in Figure 16 and Figure 17, respectively. A comparison Figure 10. Normalized LAPW1 benchmarks for 41 problem sizes and 5 Grid sites
110
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 11. Normalized rams_hist benchmarks on zid-cc with 19 problem sizes and 12 machine sizes
Figure 12. Normalized rams_hist benchmarks on hc-ma with 19 problem sizes and 14 machine sizes
111
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 13. Normalized wasim_b2c benchmarks on hc-ma with 9 problem sizes and 5 Grid sites
of two different versions of LAPW1 (32-bit versus 64-bit version) on karwendel is presented in Figure 18. These graphs were generated from the application benchmarks when only one benchmark measurement for the 64-bit version was made. To give a glimpse of the variability in the quantitative comparisons of different Grid sites for different applications, we present our experimental results in Figure 19. As shown in this figure, the agrid1 and altix1.uibk Grid sites yielded different execution time ratios for the three different applications. For WIEN2k this ratio is 2.37, for Invmod 10.37, and for MeteoAG 1.71. It is noteworthy that these ratios are irrespective of the total execution times on these Grid sites. This is the reason that why benchmarks for individual resources (e.g. CPU, memory) do not suffice for application performance and scalability predictions. Furthermore, considering one application, the comparison of execution times on Grid sites yields different ratios for different problem sizes. This performance behavior of Grid applications urged us to make a full factorial design of experiments on the Grid, rather than modeling individual applications analytically which is complex and inefficient. The execution time ratios of the two Grid sites altix1.uibk and agrid1 for 41 different problem sizes are shown in Figure 20.
Prediction Accuracy Figure 21 and Figure 22 show the graphs of comparison between the measured and predicted values for LAPW1 and wasim_b2c, respectively. The lowest curves in both figures represent the execution values on agrid1 taken as reference Grid site. The values of execution times of these activities on four other Grid sites were calculated through the normalization process. We have used the reference point available from the training set for normalization. Every two curves of measured and predicted values are very
112
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 14. Performance benchmark and Grid site comparison for 41 problem sizes of LAPW1 and five Grid sites
Figure 15. Performance benchmark and Grid site comparison for 9 problem sizes of wasim_b2c and five Grid sites
113
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 16. Performance benchmark and Grid site comparison for 18 problem sizes of rams_hist and 12 machine sizes on zid-cc
Figure 17. Performance benchmark and Grid site comparison for 18 problem sizes of rams_hist and 14 machine sizes on hc-ma
114
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 18. 32 bit versus 64 bit performance benchmark and comparison for different problem sizes on karwendel
Figure 19. Quantitative performance comparison of altix1 and agrid1 for three workflow applications
115
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 20. Execution times ratios for altix1.uibk and agrid1 for 41 problem sizes
much similar. However, we can see that they are closest near the reference problem size and have little differences as the distance from the reference problem size increases. Due to this reason, we always take the reference problem size as close as possible to the target problem size. We observed a maximum average variation of 10% from the actual values (obtained from real runs) in our performance and scalability prediction, which means 90% accuracy in our predictions with a maximum standard deviation of 2%. As we get more data during the actual runs, it will increase the probability of finding closer problem sizes other than the one obtained during the benchmarking phase, to be used in the normalization and thus increase the accuracy even beyond 90%.
FUTURE TRENDS In the future we plan to enhance our present work in multiple dimensions. First, we aim to refine the experimental design phase to further reduce the number of experiments on one Grid site (with full factorial experiments) by applying intelligent space search methods. In the beginning this will be done with the help of end-users, and later we plan to automate it for different applications. Second, we intend to make another set of benchmarks by keeping track of memory used for different problem sizes of an application. This will help in translating application performance across different machines with different memory capacities, including performance variations due to paging in case of data-intensive applications. Third, we are also enhancing our present work towards application benchmarking at the level of Grid constellations comprising of multiple sites spreading across multiple Virtual Organizations. Fourth, we plan to incorporate application throughput information for performance transformation across the
116
Benchmarking Grid Applications for Performance and Scalability Predictions
Figure 21. Comparison of real and predicted values for LAPW1
Figure 22. Comparison of real and predicted values for wasim_b2c
platforms and learn from previous errors in predictions. Last but not least, we want to find the effect of prediction inaccuracies in scheduling workflows.
117
Benchmarking Grid Applications for Performance and Scalability Predictions
CONCLUSION Application benchmarks provide a concrete basis for performance analysis and predictions incorporating variations in the problem and machine sizes on different platforms, and for real quantitative comparison of different Grid sites. Efficient and reliable design of experiments to support automatic benchmarking for the training set of application performance prediction on the Grid is of crucial importance. We proposed in this paper an effective experimental design through a step-by-step controlling mechanism that reduces the combinations of the factors affecting the application performance prediction. Our scalable approach is based on two intra- and inter-platform performance sharing and translation mechanisms that reduce the number of benchmarking experiments in the training phase to a complexity linear with the number of problem sizes, the size of one Grid site, and the number of Grid sites. Benchmarking an application with our method requires executing a full factorial set of experiments on one Grid site, and a scalability analysis for different machine sizes for a reference problem size. Using this information, predicting the performance of the application for an arbitrary problem size and machine size on another Grid site requires performing one single additional benchmarking experiment and then applying the inter- and intra-platform translation mechanisms. We demonstrated experimental results for three real-world applications in the Austrian Grid environment. In our experiments we achieved a 77% − 99% reduction in the number of experiments while maintaining 90% accuracy in the prediction results.
REFERENCES Afgan, E., Velusamy, V., & Bangalore, P. (2005). Grid resource broker using application benchmarking. European Grid Conference, (LNCS 3470, pp. 691-701). Amsterdam: Springer Verlag. Arpaci-Dusseau, R. H., Arpaci-Dusseau, A. C., Vahdat, A., Liu, L. T., Anderson, T. E., & Patterson, D. A. (1995). The interaction of parallel and sequential workloads on a network of workstations. SIGMETRICS, (pp. 267-278). Bailey, D., Barszcz, E., Barton, J. T., Browning, D. S., Carter, R. L., & Dagum, L. (1991). The NAS parallel benchmarks. The International Journal of Supercomputer Applications, 5(3), 63–73. Banks, T. (2006). Web services resource framework (WSRF). Organization for the Advancement of Structured Information Standards (OASIS). Berman, F., Casanova, H., Chien, A. A., Cooper, K. D., Dail, H., & Dasgupta, A. (2005). New Grid scheduling and rescheduling methods in the GrADS project. International Journal of Parallel Programming, 33(2-3), 209–229. doi:10.1007/s10766-005-3584-4 Cotton, W., Pielke, R., Walko, R., Liston, G., Tremback, C., & Jiang, H. (2003). RAMS 2001: Current status and future directions. Meteorology and Atmospheric Physics, 82(1-4), 5–29. doi:10.1007/s00703001-0584-9
118
Benchmarking Grid Applications for Performance and Scalability Predictions
Czajkowski, K., Fitzgerald, S., Foster, I., & Kesselman, C. (2001). Grid information services for distributed resource sharing. 10th International Symposium on High Performance Distributed Computing (pp. 181-194). San Francisco: IEEE Computer Society Press. De Roure, M., & Surridge, D. (2003). Interoperability challenges in Grid for industrial applications. GGF9 Semantic Grid Workshop, Chicago. Dikaiakos, M. D. (2007). Grid benchmarking: vision, challenges, and current status. [New York: Wiley InterScience.]. Concurrency and Computation, 19, 89–105. doi:10.1002/cpe.1086 Dixit, K. M. (1991). The SPEC benchmarks. Parallel Computing, 17(10-11), 1195–1209. doi:10.1016/ S0167-8191(05)80033-X Dongarra, J., Luszczek, P., & Petitet, A. (2003, August). The LINPACK Benchmark: past, present and future. Concurrency and Computation, 15(9), 803–820. doi:10.1002/cpe.728 Duan, R., Prodan, R., & Fahringer, T. (2006). Run-time optimization for Grid workflow applications. International Conference on Grid Computing. Barcelona, Spain: IEEE Computer Society Press. Fahringer, T., Prodan, R., Duan, R., Hofer, J., Nadeem, F., Nerieri, F., et al. (2006). ASKALON: A development and grid computing environment for scientific workflows. In I. J. Taylor, E. Deelman, D. G. Ganon, & M. Shields (Eds.), Workflows for e-Science (p. 530). Berlin: Springer Verlag. Foster, I., & Kesselman, C. (1997). Globus: A metacomputing infrastructure toolkit. International Journal of Supercomputer Applications and High Performance Computing, 11(2), 115–128. doi:10.1177/109434209701100205 Foster, I., & Kesselman, C. (2004). The Grid: Blueprint for a future computing infrastructure (2 Ed.). San Francisco: Morgan Kaufmann. Heymann, E., Fernandez, A., Senar, M. A., & Salt, J. (2003). The EU-Crossgrid approach for grid application scheduling. European Grid Conference, (LNCS 2970, pp. 17-24). Amsterdam: Springer Verlag. Hockney, R., & Berry, M. (1994). PARKBENCH report: public international benchmarks for parallel computers. Science Progress, 3(2), 101–146. Iosup, A., & Epema, D. H. (2006). GRENCHMARK: A framework for analyzing, testing, and comparing grids. International Conference on Cluster Computing and the Grid (pp. 313-320). Singapore: IEEE Computer Society Press. Iosup, A., & Epema, D. H. (2007). Build-and-test workloads for Grid middleware: Problem, analysis, and applications. International Conference on Cluster Computing and the Grid (pp. 205-213). Rio de Janeiro, Brazil: IEEE Computer Society Press. Jarvis, S. A., & Nudd, G. R. (2005, February). Performance-based middleware for Grid computing. Concurrency and Computation: Practactice and Experience, 17(2-4), 215–234. doi:10.1002/ cpe.925
119
Benchmarking Grid Applications for Performance and Scalability Predictions
Mohamed, H. H., & Epema, D. H. (2005). Experiences with the KOALA co-allocating scheduler in multiclusters. International Conference of Cluster Computing and the Grid (pp. 784-791). Cardiff, UK: IEEE Computer Society Press. Montgomery, D. C. (2004). Design and analysis of experiments (6 ed.). New York: Wiley. Prodan, R., & Fahringer, T. (2008, March). overhead analysis of scientific workflows in grid environments. Transactions on Parallel and Distributed Systems, 19(3), 378–393. doi:10.1109/ TPDS.2007.70734 Raman, R., Livny, M., & Solomon, M. H. (1999). Matchmaking: An extensible framework for distributed resource management. Cluster Computing, 2(2), 129–138. doi:10.1023/A:1019022624119 Schüller, F., Qin, J., Nadeem, F., Prodan, R., Fahringer, T., & Mayr, G. (2006). Performance, scalability and quality of the meteorological grid workflow MeteoAG. In Austrian Grid Symposium. Innsbruck, Austria: OCG Verlag. Schwarz, K., Blaha, P., & Madsen, G. K. (2002). Electronic structure calculations of solids using the WIEN2k package for material sciences. Computer Physics Communications, 147(71). Schwiegelshohn, U., & Yahyapour, R. (2000). Fairness in parallel job scheduling. Journal of Scheduling, 3(5), 297–320. doi:10.1002/1099-1425(200009/10)3:5<297::AID-JOS50>3.0.CO;2-D Seltzer, M. I., Krinsky, D., & Smith, K. A. (1999). The case for application-specific benchmarking. Workshop on Hot Topics in Operating Systems (pp. 102-109). Rio Rico, AZ: IEEE Computer Society Press. Siddiqui, M., Villazon, A., Hoffer, J., & Fahringer, T. (2005). GLARE: A Grid activity registration, deployment, and provisioning framework. Supercomputing Conference. Seattle, WA: IEEE Computer Society Press. Snavely, A., & Weinberg, J. (2006). Symbiotic space-sharing on SDSC’s datastar system. Job Scheduling Strategies for Parallel Processing. (LNCS 4376, pp.192-209). St. Malo, France: Springer Verlag. Theiner, D., & Rutschmann, P. (2005). An inverse modelling approach for the estimation of hydrological model parameters. (I. Publishing, Ed.) Journal of Hydroinformatics. Tirado-Ramos, A., Tsouloupas, G., Dikaiakos, M. D., & Sloot, P. M. (2005). Grid resource selection by application benchmarking: A computational haemodynamics case study. International Conference on Computational Science. (LNCS 3514, pp. 534-543). Atlanta, GA: Springer Verlag. Tsouloupas, G., & Dikaiakos, M. D. (2007). GridBench: A tool for the interactive performance exploration of Grid infrastructures. Journal of Parallel and Distributed Computing, 67(9), 1029–1045. doi:10.1016/j.jpdc.2007.04.009 Van der Wijngaart, R. F., & Frumkin, M. A. (2004). Evaluating the information power Grid using the NAS Grid benchmarks. International Parallel and Distributed Processing Symposium. Santa Fe, NM: IEEE Computer Society Press.
120
Benchmarking Grid Applications for Performance and Scalability Predictions
Wieczorek, M., Prodan, R., & Fahringer, T. (2005). Scheduling of scientific workflows in the ASKALON Grid environment. SIGMOD Record, 09. Wolski, R. (2003). Experiences with predicting resource performance on-line in computational grid settings. ACM SIGMETRICS Performance Evaluation Review, 30(4), 41–49. doi:10.1145/773056.773064 World Wide Web Consortium (W3C). (n.d.). Web services activity. Retrieved from http://www. w3.org/2002/ws/
KEY TERMS AND DEFINITIONS Benchmark: A measurement to be used as a reference value for future calculations such as performance predictions. Experimental Design: Design of all information gathering exercises where variation is present, whether under the full control of the experimenter or not. Grid: A geographically distributed hardware and software infrastructure that integrates high-end computers, networks, databases, and scientific instruments from multiple sources to form a virtual supercomputer on which users can work collaboratively within virtual organizations. Performance Prediction: Estimation of the execution time of an application for a certain problem size in a certain configuration (e.g. machine size) on the target computer architecture. Scalability: The ability of a system to either handle growing amounts of work without losing processing speed. Scheduling: The process of finding an appropriate execution resource to each atomic activity of a large application; scheduling is usually employed for parallel applications, bags of tasks, and workflows and is an NP-complete problem for certain objective functions such as execution time. Scientific Workflow: A large-scale loosely coupled application consisting of a set of commodity off-the-shelf software components (also called tasks or activities) interconnected in a directed graph through control flow and data flow dependencies.
121
Section 2
P2P Computing
123
Chapter 6
Scalable Index and Data Management for Unstructured Peer-To-Peer Networks Shang-Feng Chiang National Taiwan University, Taiwan Kuo Chiang National Taiwan University, Taiwan Ruo-Jian Yu National Taiwan University, Taiwan Sheng-De Wang National Taiwan University, Taiwan
ABSTRACT In order to improve the scalability and reduce the traffic of Gnutella-like unstructured peer-to-peer networks, index caching and controlled flooding mechanisms had been an important research topic in recent years. In this chapter the authors will describe and present the current state of the art about index management schemes, interest groups and data clustering for unstructured peer-to-peer networks. Index caching mechanisms are an approach to reducing the traffic of keyword querying. However, the cached indices may incur redundant replications in the whole network, leading to the less efficient use of storage and the increase of traffic. They propose a multiplayer index management scheme that actively diffuses the indices in the network and groups indices according to their request rate. The peers of the group that have indices with higher request rate will be placed in layers that receive queries earlier. Their simulation shows that the proposed approach can keep a high success query rate as well as reduce the flooding size.
DOI: 10.4018/978-1-60566-661-7.ch006
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Scalable Index and Data Management for Unstructured P2P Networks
INTRODUCTION With the growth of the Internet, peer-to-peer (P2P) systems have become an important paradigm in designing large scale distribution systems. Peer-to-peer systems (Androutsellis-Theotokis, & Spinellis, 2004) provide effective ways of sharing data and can be based on overlay networks, which are classified by the degree of decentralization. The three categories are as follows: purely decentralized, partially decentralized, and hybrid decentralized architecture. Supporting efficient search of desired documents has been the most important issue in a decentralized peer-to-peer network. The overlay for decentralized peer-to-peer networks can be either unstructured or structured based on some distributed hash functions. Gnutella and Napster are pioneers in peer-to-peer file sharing systems and belong to the unstructured ones. A class of structured peer-to-peer networks uses DHT (Distributed Hash Table) to maintain the shared documents. Distributed hash tables (DHTs) make use of hashing functions to provide distribution and lookup services. In this way, any participating node can efficiently retrieve the value associated with a given key. Responsibility for maintaining the mapping from names to values is distributed among the nodes, in such a way that a change in the set of participants causes a minimal amount of disruption. DHTs are typically designed to scale a large number of nodes and handle nodes’ arrival and departure. With a routing table, all the participating nodes only need to communicate with a small fraction of all the nodes in a structured overlay network. On the other hand, the unstructured peer-to-peer networks often rely on flooding mechanisms to search the desired objects. As a result, it needs to use techniques like index caching, active replication, or controlled flooding, to reduce the query traffic. The search algorithm of Gnutella use a kind of flooding method to discover objects, which sends queries to all nodes within a given TTL value. However, the mechanism is not scalable, since the query messages will grow exponentially due to its blind search method. In this chapter, we will discuss some scalable techniques for index and data management for unstructured peer-to-peer networks. The concepts of interest group and data clustering will also be addressed. We also propose an index diffusion scheme to maintain a high success query rate and reduce the traffic load, for unstructured peer-to-peer systems.
BACKGROUND AND RELATED WORK BitTorrent BitTorrent is a peer-to-peer communication protocol (Cohen 2002) that can distribute large amounts of data widely without the original distributor incurring the entire costs of hardware, hosting, and bandwidth resources. Instead, when data is distributed using the BitTorrent protocol, each recipient supplies pieces of the data to newer recipients, reducing the cost and burden on any given individual source, providing redundancy against system problems, and reducing dependence on the original distributor.
124
Scalable Index and Data Management for Unstructured P2P Networks
Blind Search Methods Most search methods in Gnutella-like peer-to-peer networks can be categorized into blind search methods and informed search methods (Tsoumakos, & Rousseopoulos, 2006). In blind search methods, there is no mechanism to keep the query results, to judge the best query path, or to use some other information to reduce traffic. Blind search confines the nodes to transmit messages to some adjacent nodes instead of all adjacent nodes without using the information of messages or choosing the best path for transmitting. The typical systems include Gnutella, Modified-BFS (Kalogeraki, Gunopulos, & Zeinalipour-Yazti 2002), Random Walks (Lv, Cao, Cohen, Li, & Shenker 2002), and Dynamic Query (Fisk, 2003) (Ripeanu, Foster, & Iamnitchi 2002).
Index Caching Mechanisms Some informed search methods are efficient in reducing flooding messages by using a class of caching mechanisms. In a normal Uniform Index Caching (UIC) mechanism, all peers in the path of a query record the query hit results in their caches. DiCAS records the query hit results in a multilayer peer-topeer network (Wang, Xiao, Liu, & Zheng, 2004). In DiCAS with m layers, each peer randomly takes an initial value in a certain range, for example, 0 to m-1, as a group id when it joins a peer-to-peer network. A query qr matches a peer if and only if the peer’s group id matches the following equation: id = hash(qr) mod m
(1)
Unstructured peer-to-peer networks often use partially centralized architecture to reduce the query traffic. Some nodes in the networks play specific roles, for example, managing network configuration, monitoring network status, and forwarding messages to other peers. Distributed caching (Ambastha, Beak, Gokhale, & Mohr, 2003) and adaptive search (DiCAS) algorithm has been proposed to reduce network search traffic with the help of small cache space contributed by each individual peer. With indices passively cached in a group of peers based on a predefined hash function, the DiCAS protocol can significantly reduce network search traffic. Based on the DiCAS algorithm, we will propose an index management scheme to enhance the search performance.
Interest Group and Data Clustering The concept of interest groups (Chao 2006) can play an important role in designing peer-to-peer systems. Everyone has his own interest and the communities in the Internet also reflect the fact. If we can place files with the same attribute or files interested by the same group of users in the same cluster, the users can easily find the files by searching for them within the same cluster. It is worthy of noticing that the resource types themselves present the properties of fractals both in coarse and fine classifications of resources. To further improve the efficiency, locality should be considered by multicast or routing algorithms of the application layer when constructing overlay networks (Zhang et al 2004). It is noted that even better performance can be achieved if we combine the locality and the concept of interest group.
125
Scalable Index and Data Management for Unstructured P2P Networks
Popularity of Content: The shared contents in a peer-to-peer network in general follow a kind of probability distribution that reflects some forms of popularity. We would like to model this kind of distribution, which is close to the realistic cases, in peer-to-peer networks. In many cases, keywords of queries may follow a Zipf distribution. The distribution model of content popularity described in (Saleh, Hefeeda, 2006) follows a Mandelbrot-Zipf distribution (Silagadze, 1997). The Mandelbrot-Zipf distribution, a general form of the Zipf-like distribution with an extra parameter, defines the probability of accessing an object at rank i out of N available objects as: p(i ) =
HN ,
s, q
(i +q )s
,
N
H N , s, q = å i =1
1 (i +q )s
,
q ³0
(2)
Here, s is the skewness factor, and q is the plateau factor. In (Saleh, Hefeeda, 2006), it is observed that the typical value for s is between 0.4 and 0.7, and typical value for q is between 5 and 60. MandelbrotZipf distribution degenerates to a Zipflike distribution with a skewness factor s if q = 0. In our simulation, we will use these parameters to setup the simulation environment in order to make the simulation model close to real cases.
AN INDEx DIFFUSION MECHANISM Request Popularity and Disposition In order to group indices, we cluster the indices of files with similar properties into the same groups. In structured peer-to-peer networks, each keyword is exactly matched by a single node. The architecture of structured peer-to-peer network may be the best choice for grouping the indices by keywords. Search in structured peer-to-peer networks is also more efficient than in unstructured peer-to-peer networks. For an unstructured peer-to-peer network, we group indices by the request popularity instead of keywords. The request popularity is a special property of any shared files, and the request popularity cannot be calculated only by the information of sharing files. To measure the request popularity of the shared files, the peer that owns the file must update the hit counts by listening to the queries or messages to update indices. This is similar to the webpage ranking. A popular webpage will be marked with a higher rank value by the search engine. And the search engine can sort the search results by the rank of each webpage. So, we can assign a higher rank value to a more popular file. The indices of the more popular files can be distributed to peers that lie in more ahead locations so that a query can reach it earlier. We design a hierarchical multilayer peer-to-peer network, and the priorities of layers are different. The top layer has the highest priority, and queries always reach the peers that are in the top layer first. Indices of the most popular files are placed in the top layer. We will move those file indices whose request rates are growing up to an upper layer so that they can be reached earlier in the subsequence queries. The indices of the files that become unpopular will be replaced by more popular ones. There is a situation needed to be considered. When having new files inserted into the peer-to-peer network, we suppose they are popular so we insert their indices into the top layer to make them be reached as
126
Scalable Index and Data Management for Unstructured P2P Networks
Figure 1. The multilayer structure
earlier as possible.
Network Architecture In order to maintain our multilayer architecture easily and balance the load in each layer, we divide the network into three layers (0 to 2) and 7 groups (0 to 6). The architecture is shown in Figure 1. Each peer randomly selects a value (0 to 6) as its group id when it joins the network. The top layer, Layer-0, contains only one group (Group-0), and the second layer contains 2 groups (Group-1 and Group-2). The other 4 groups are assigned to the third layer. Because only a few files are popular, Layer-0 has only one group. The index diffusion will be carried out by the owner of the file according the request rate, which is characterized by the query hit counts occurred in some period, T. The owner of a file will diffuse the index in Layer-0 if the hit count is larger than 4 in T. And if the hit counts are 2 or 3 in T, the indices will be randomly diffused to one group in Layer-1. In order to control the traffic, indices in Layer-2 will never expire. The indices in Layer-2 will be removed if and only if the procedure of index update fails. So, when a new file is inserted to the network, the file owner will not only place file indices to Layer-0, but also will randomly select one group in Layer-2 to keep the file index.
Control of Indices Most index caching mechanisms are based on passively overhearing the traffic or actively querying and collecting the information about shared files from their neighbors. Overhearing does not cost any additional overhead about traffic by caching the results of query hits because it does not affect the original flooding algorithms. However, the active querying and collecting the locations of shared files will produce overheads due to the update mechanism. The overhead is significant when peers frequently leave or join the overlay network. Obviously, the hit counts of shared files that contain more popular keywords will be higher than others. As a result, passive caching methods will cache more copies of indices of popular items than unpopular ones. The advantage is that the popular files will be found easily and quickly because these files are cached widely over the network. In this case, a flooding algorithm with a low TTL value is sufficient to find such an item. However, there is no method to control the amount of indices of an item in the index caching mechanisms. Also, it produces at least two disadvantages: (1)
127
Scalable Index and Data Management for Unstructured P2P Networks
it is hard to find new shared files that contains popular keywords; (2) the information of cache may be invalid in peer-to-peer networks with high churn rate. In order to limit the traffic incurred by flooding, some search methods assign a smaller TTL value in the process of search. Flooding with a small TTL will only cover a small part of networks, so the peers that have newer files may not be included in the range of flooding. On the other hand, in a peer-to-peer network, the destination peer that was pointed to by an index in the index cache may have left the network. In the DiCAS algorithm, peers use a hash method to redirect query messages in the multilayer peer-to-peer network. By this method, search is more efficient than the original uniform index caching mechanism in terms of traffic. But there is one issue about the number of layers in the multilayer peer-to-peer network. If we insert more layers in the peer-to-peer network, the probability of finding a desired file in a matched layer will be lower. This may limit the performance of query success rate in the peer-to-peer network, and the amount of results may not be enough to meet the preset expected number of matched results. The proposed approach of the active index diffusing (AID) scheme can overcome these problems in index caching mechanisms. In our scheme, we group the peers that share the same files in a cluster, and they could diffuse indices actively. There are four main strategies in the AID (Active Index Diffusion) scheme: 1.
128
Clustering peers that share the same file names: The main concept of our AID scheme is similar to some existing peer-to-peer applications, such as BitTorrent. There are several trackers that record owners of the files and peers that are downloading the files in BitTorrent. These trackers will provide the information when peers request the files. Peer-to-peer networks like BitTorrent are efficient in getting peer lists from trackers, so we group peers that share the same file names in a cluster. In the AID scheme, each peer knows other peers that share the file with the same file names. In other words, every peer could play the role just like trackers in BitTorrent. If a peer requests the file, the owner of the file will provide the information of the file. Another reason of grouping files with the same file names is that there are more and more fake files appearing in peer-to-peer networks. Fake files are detected in KaZaA, while files may be infected by virus in Winny and Share. Grouping these fake files and real files together, we can apply some method to differentiate between fake and real files with a tag. The tag may help peers tell if the file is real. 2. Index updated when an index hit occurs: As we have discussed, the request popularity characterizes our index diffusion scheme. We define the request popularity by the number of index hit counts over a timeout period, T. In each cluster, owners will elect one peer as the master of the file. The master may be the one that has the longest online time in the same cluster. When the master leaves the network, peers will reelect one peer as the master. When an index hit occurs in a peer, the peer will send an index update message to the file owner. The owner of the file then selects a peer in its cluster randomly to carry out the index update. The file owner will also send an index update message to the master. The master in each cluster keeps the hit count obtained from the index update messages. 3. Actively diffusing indices: According to the hit rate, the master will actively diffuse its indices to the peers in an appropriate layer when the indices expire. We denote the value of timeout as T. The value of T is should not be too small such that masters may update indices too often. In order to control the traffic of actively diffusing indices, T must be assigned a value larger than a certain number that may be related to the network size and the amount of shared files. Assume that a network has N peers, the index replication rate is r, totally I
Scalable Index and Data Management for Unstructured P2P Networks
Figure 2. Index copy when peer joins
different files are shared, and the maximal amount of messages as S. If you want to limit the number of messages S to satisfy the following inequality: S £ Total pupular indices that need updates in T = N × r × I × k /T T
(3)
So we can determine the value of T by: T ³ N ×r ×I ×k /S
(4)
where k is the probability if a file is popular. In (Chawathe, Y., Ratnasamy, S., Breslau, L., Lanham, N., & Shenker, S., 2003), it is estimated that 32% to 42% queries are repeated. According to Zipf distribution, these queries are only requesting files with small sizes. Thus, we assign a small value to k. 4.
Copy indices when peer joins: The basic procedure of joining our network is the same as Gnutella/ LimeWire (Fisk 2003). Because we wish to control the flooding size and keep the hit rate steady, the index replication rate should be kept in a constant value. In a peer-to-peer network, we cannot control the departure of each peer, but we could do something when peers join in. When peers receive copy request messages, they will replicate a part of their indices to the newly-joining peer. The method can make the replication ratio in a stable value. After finishing the joining procedure, the newcomer will request indices replication by sending n copy request messages to n connected peers. If a peer receives a copy request message, it will reply with 1/n of indices in its index cache to the newcomer. The example is shown in Figure 2. As a result, the index replication ratio will
129
Scalable Index and Data Management for Unstructured P2P Networks
Table 1. p’(F) and F’ in different network sizes Peers
10000
100000
p’(F)
F’
p’(F)
F’
6 groups
95.57%
30.26303
95.48%
30.31680
7 groups
97.43%
29.01158
97.35%
29.06710
8 groups
98.52%
28.04401
98.46%
28.10261
9 groups
99.15%
27.30189
99.11%
27.35940
10 groups
99.52%
26.73488
99.49%
26.78876
keep a constant value because the new peer will keep 1 = n × 1/n table of indices.
Flooding of Query In peer-to-peer networks, if the file indices are diffused in the whole network and there is no intelligent method (just flooding with blind) applied to search, the query success rate can be described by a hypergeometric distribution. By definition, if a random variable X follows the hypergeometric distribution with parameters N, D, and n, the probability of getting exactly k successes is given by, f (X = k ; N , D, n ) =
(kD )(nN--kD ) (nN )
(5)
where N is the whole sample space, D is the amount of total desired items, and n is the amount of samples. Now, let a simple peer-to-peer network be consisted of N peers and the index replication rate is r. Then, the expression of the probability model is: f (X = k ; N , rN , m ) =
(rN )((m1--rk)N ) k (mN )
(6)
If the query messages had been sent to m peers, the success rate, hm, would be equal to: hm = 1-f (X = 0; N , rN , m )
(7)
Generally speaking, a higher flooding size incurs more traffic overheads, but the success rate can also be higher. We wish that our flooding method in each group is efficient in the aspect of the flooding size and success rate, so we modify the search method of dynamic query to suit our architecture. The concept is to satisfy the demand of files in dynamic query. In our search method, we expect the success rate higher than a certain value if the indices of desired items are in the group. Trying to make our network scalable, we set the basic flooding size F of each group to the same value. Searching in each group contains two iterations and begins with sending query messages to F peers in
130
Scalable Index and Data Management for Unstructured P2P Networks
Figure 3. Example of routing path 1 with the modified dynamic query
the first iteration. The message will be flooded to another F peers if and only if there is no hit message returned in the first iteration. When the network is divided into g groups, the success rate of a search in a group having the indices of desired files is: hm = 1-f (X = 0; N , rN , m )
(8)
The final success rate with two iterations can be written as: p ¢(F ) = p(F ) + (1 - p(F )) × p(F ) = 2p(F ) - p(F )2
(9)
Figure 4. Example of routing path 1 with the modified random walk
131
Scalable Index and Data Management for Unstructured P2P Networks
Figure 5. Example of routing path 2 with the modified random walk
The value of p’(F) is very close to p(2F), and the average flooding size F’ is equal to: F ¢ = F + (1 - p(F )) × F = 2F - F × p(F )
(10)
Because p(F) is close to 1, the average flooding size, F’ will approach F. If we flood a query to F’ peers directly, the value of p(F’) is lower than p’(F). We set the value of F as 25 and then calculate p’(F) and F’ with different network sizes. The results are shown in the Table 1. Our architecture with 10000 peers reaches a success rate of 97.43%, with F’ = 29.01158 for the 7-group peer-to-peer system. When the network size is ten times larger, the success rate is 97.35%, with F’ = 29.06710. It shows that the average flooding sizes and success rates in different network sizes are quite similar, so there is no
Figure 6. Flooding size
132
Scalable Index and Data Management for Unstructured P2P Networks
Figure 7. Average success rate
problem with the scalability of our network.
Modified Search Methods Because our peer-to-peer network is based on a multilayer architecture, the existing search method does not be suitable for our architecture. We should adapt some existing blind search methods for our peer-to-peer network. 1.
2.
Dynamic query: A requesting peer randomly selects a peer from each group as the forwarder; then, the query will start with sending a query message to the forwarder of Group-0. This forwarder will send the query in Layer-0. If hit results are not enough, the query messages will be sent to Group-1 and Group-2 peers in Layer-1. If the results returned from Layer-0 and Layer-1 are not satisfied with desired amount, the query will reach the final layer, Layer-2. Figure 3 illustrates an example of modified dynamic query. Random walks:We adopt an F-walker random walk algorithm and each walker will send queries in each group at most 2 times, where F will be set to 25. There are 25 walkers sent by a requesting peer, and the walkers start walking in the Group-0. Walkers will send queries in each group at most 2 times and end in Group-3 or Group-6 of the Layer-2. The examples of routing path are shown in Figure 4 and Figure 5. There are two cases where the walker will stop: one is the walker had finished the query, and the other one is when a hit occurs.
133
Scalable Index and Data Management for Unstructured P2P Networks
Figure 8. Average hit files
SIMULATION RESULTS In our simulations, there are 10000 peers in the unstructured peer-to-peer network, and these peers are divided into 3 layers and 7 groups. The basic flooding size F is set to be 25 peers for each group. The timeout value T is 2500. File names in our simulations are titles of 1268 distinguishing books, and the popularity of file names is modeled by the Mandelbrot-Zipf distribution. Each book has an average of 7 keywords. Finally, we totally assign 20000 query iterations in each simulation, and the parameters of query keywords in the Mandelbrot-Zipf distribution are the same as the parameters that the file names used. As suggested by Share, we tried 2 different experiment setups of the Mandelbrot-Zipf distribution, where one is s = 0.4 and q = 60, and the other one is s = 0.7 and q = 5. In the following experiments, results are slightly different. We used m-zipf(0.7, 5) and m-zipf(0.4, 60) to distinguish these two setups. In the configurations with m-zipf(0.7, 5), we totally inserted 3415 files to the whole network. And we assigned 1866 files to the networks that is configured with m-zipf(0.4, 60). In (Yinglian and O’Hallaron 2002), the authors only experimented on the DiCAS peer-to-peer network with 2-layer configuration. We will make a comparison in query success rates of the DiCAS in different layer configurations. The network degree is modified from 5 to 25, and the cache size is set to 50. The dynamic query search method was implemented and modified for the DiCAS. First, we want to know how the flooding size will be reduced when we insert more layers in the DiCAS. The simulations run in 2- to 4-layer configurations. Due to the use of the index caching mechanism and the search method of dynamic query, the flooding sizes are decreased when more query iterations are submitted. The amount
134
Scalable Index and Data Management for Unstructured P2P Networks
Figure 9. Average duplicated rate per hit
of desired files of dynamic query is set to 4. After the 10000th query iteration, the flooding sizes become more stable than before, so we calculate the average flooding size from the 10000th query iteration to the 20000th one. Figure 6 shows that the average flooding sizes of different multilayer configurations in the DiCAS. As the result of average flooding sizes in the DiCAS, the sizes are larger than 850 peers in the original 2-layer configuration with m-zipf(0.7, 5) and m-zipf(0.4, 60). When the amount of layers grows, the flooding sizes are decreased evidently. In the 4-layer configuration, the flooding size is only half of the 2-layer configuration. We can also notice that the traffic in m-zipf(0.4, 60) is larger than that in
Figure 10. Average messages of DiCAS
135
Scalable Index and Data Management for Unstructured P2P Networks
Figure 11. Average messages of the AID
m-zipf(0.7, 5) in this figure. Compared with the results in the DiCAS, the proposed method has smaller flooding size. Furthermore, more layers in the DiCAS cause the reduction of the query success rate, as the simulation results shown in Figure 7. In order to make a fair comparison, the success rates are calculated by the success hit count from the 10000th query iteration to the 20000th one too. During that period, the success rates are more stable than previous section. In the 2-layer configuration, hit rates are close to 95%. But the query success rate in the 4-layer configuration with m-zipf(0.4, 60) is lower than 85%. According to this figure we can see that the query success rate decreases when the number of layers increases. In our AID scheme with two different search methods, dynamic query (DQ) and random walks (RW), the query success rates of each search methods could be seen in Figure 7. The simulation results about the success rates of each method are all higher than 98%, and some of them can reach 99%. Obviously, the success rate is closer to 1 in the proposed AID scheme than the DiCAS. Figure 6 also shows that the average flooding sizes of each search method in the AID scheme are smaller than the DiCAS. And Figure 8 is about the number of hit files per query of the DiCAS and the AID scheme. The other problem for index caching mechanisms like DiCAS is that we can get a lot of redundant indices from the hit messages, but these indices only cover a few different files. In other words, there are too many indices replicated in the system. Although more layers in the network could reduce the replicated indices per query, the success rate became lower. We also calculated the average replicated rate per query in Figure 9 to compare the DiCAS and our AID scheme. The ratios in the AID scheme are much smaller than DiCAS, and the ratios are between 1.8 and 2.6. It shows that our AID scheme reduces more hit messages about these indices, which are replicated in each search. We can also compare the total messages in the DiCAS and our AID scheme. The results are shown in Figure 10 and Figure 11. When networks become stable, the average number of messages per query in the DiCAS approach is larger than 1000, but in our AID scheme, it only costs 270 to 340 messages. Finally, the MandelbrotZipf distribution with s = 0.7 and q = 5 in the DiCAS could get more files and a higher success rate in a smaller flooding size. The main difference between our AID scheme and the DiCAS scheme is that our modified search methods try to maximize the search success rate, so the values of success rates in the AID scheme are quite similar in different Mandelbrot-Zipf configurations.
136
Scalable Index and Data Management for Unstructured P2P Networks
DISCUSSIONS AND FUTURE TRENDS We understand that the popularity of files cannot be determined only by a period of time T. In other words, judging which layer to diffuse a file will be better if we also take the hit count in the past into consideration. Otherwise, if the popularity of files varies rapidly, they will bounce between different layers frequently, even though it is unnecessary, after each period time T. Hence we introduce the concept of moving average which can smooth a short-term oscillation and make the value which represents the popularity of files more authentic in case of short-term abnormal burst or tranquility. Assume HN is the hit counts observed in time interval [(N-1)*T, N*T], and W is the weighting we assign to HP(N-1), which is the value representing the popularity of files in time interval [(N-2)*T, (N-1)*T]; HN *(1-W) means that we assign the weighting (1-W) to HN with respect to the weight W to HP(N-1). We can use an exponential moving average to estimate the popularity of files HP(N) in time interval [(N-1)*T, N*T] as follows. HP(N) = HP(N-1) * W + HN *(1-W)
(11)
Furthermore, we can also make a clear definition for “popular files” on our own by using some learning algorithm. By training a large amount of data, the method can be more efficient in deciding which layer to diffuse files.
CONCLUSION The experimental results show that our architecture is efficient in keeping a high success rate of queries and reducing the flooding size. The proposed approach can also result in an index table with less redundant indices than the existing system DiCAS, making an efficient use of storage and does not incur too much traffic. Flooding and caching according to hashed keywords like DiCAS may cause flooding in layers that do not contain desired files, and result in a lower query hit rate. This problem is even worse in configuring the system with more layers. Compared with DiCAS, the query success rate has improvements from 95% to 98% and the traffic of messages has reduced 73% to 80%. The replicated indices of query also had been decreased to 13%. This shows that the proposed unstructured peer-to-peer system is scalable and efficient in reducing traffic and increasing hit rate.
REFERENCES Ambastha, N., Beak, I., Gokhale, S., & Mohr, A. (2003). A cache-based resource location approach for unstructured P2P network architectures. Graduate Research Conference, Department of Computer Science, Stony Brook University, NY. Androutsellis-Theotokis, S., & Spinellis, D. (2004). A survey of peer-to-peer content distribution technologies. ACM Computing Surveys, 36(4), 335–371. doi:10.1145/1041680.1041681 Chao, C.-H. (2006, April). An Interest-based architecture for peer-to-peer network systems. In Proceedings of the International Conference AINA.
137
Scalable Index and Data Management for Unstructured P2P Networks
Chawathe, Y., Ratnasamy, S., Breslau, L., Lanham, N., & Shenker, S. (2003). Making gnutella-like p2p systems scalable. In Proceedings of the 2003 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications (pp. 407-418). Cheng, A. H., & Joung, Y. J. (2006). Probabilistic file indexing and searching in unstructured peer-topeer networks. Computer Networks, 50(1), 106–127. doi:10.1016/j.comnet.2005.12.008 Cohen, B. (2002). BitTorrent Protocol 1.0. Retrieved from BitTorrent.org. Fisk, A. (2003). Gnutella dynamic query protocol v. 0.1. Retrieved from http://www9.limewire.com/ developer/dynamic query.html. Kalogeraki, V., Gunopulos, D., & Zeinalipour-Yazti, D. (2002). A local search mechanism for peer-topeer networks. In Proceedings of the Eleventh International Conference on Information and Knowledge Management (pp. 300-307). Lv, C., Cao, P., Cohen, E., Li, K., & Shenker, S. (2002). Search and replication in unstructured peer-topeer networks. In Proceedings of the 2002 ACM SIGMETRICS international conference on Measurement and modeling of computer systems (pp.258-259). Ripeanu, M., Foster, I., & Iamnitchi, A. (2002). Mapping the gnutella network: properties of large-scale peer-to-peer systems and implications for system design. IEEE Internet Computing, 6(1), 50-57. Saleh, O., & Hefeeda, M. (2006). Modeling and caching of peer-to-peer traffic. In Proc. of 14th IEEE International Conference on Network Protocols (ICNP’06), (pp. 249-258). Silagadze, Z. (1997). Citations and the Mandelbrot-Zipf’s law. Complex Systems, 11, 487–499. Stoica, R. Morris, Karger, D., Kaashoek, M. F., & Balakrishnan, H., (2001). Chord: A scalable peer-topeer lookup service for Internet applications. In ACM SIGCOMM, August, (pp. 149-160). Tsoumakos, D., & Rousseopoulos, N. (2006). Analysis and comparison of p2p search methods. In Proceedings of the 1st International Conference on Scalable Information Systems (INFOSCALE 2006), No. 25. Wang, C., Xiao, L., Liu, Y., & Zheng, P. (2004). Distributed caching and adaptive search in multilayer P2P networks. In International Conference on Distributed Computing Systems (ICDCS’04) (pp. 219-226). Yang, B., & Garcia-Molina, H. (2002). Improving search in peer-to-peer networks. In Proceedings of the 22nd International Conference on Distributed Computing Systems (ICDCS’02) (pp. 5). Yinglian, X. O’Hallaron D. (2002). Locality in search engine queries and its implications for caching. In Proceedings of the IEEE Infocom (pp. 1238-1247). Zhang, X. Y., Zhang, Q., Zhang, Z., Song, G., & Zhu, W. (2004). A construction of locality-aware overlay network: mOverlay and its performance. IEEE Journal on Selected Areas in Communications, 22(1), 18–28. doi:10.1109/JSAC.2003.818780
138
Scalable Index and Data Management for Unstructured P2P Networks
KEY TERMS AND DEFINITIONS Dynamic Query: The search technique the Gnutella adopted to reduce traffic overhead and make searches more efficient, where a search reaches only those clients which are likely to have the files and stops as soon as the program has acquired enough search results. Peer-to-Peer Networks: A network with equal peer nodes that simultaneously function as both clients and servers to the other nodes on the network. Random Walk: A search algorithm used in a peer-to-peer network where the query will be forwarded up and down the given list until a match is found, the query is aborted, or it reaches the limits of the list. Structured Peer-to-Peer Networks: A peer-to-peer network that employ a consistent protocol such as a distributed hashing function to ensure that any node can efficiently route a search to some peer that has the desired file. The consistent hashing is also used to distribute the file to a peer. Uniform Index Caching: A cache scheme where query results are cached in all peers along the query path. Unstructured Peer-to-Peer Networks: A peer-to-peer network that is formed when the overlay links are established arbitrarily.
139
140
Chapter 7
Hierarchical Structured Peer-to-Peer Networks Yong Meng Teo National University of Singapore, Singapore Verdi March National University of Singapore, Singapore Marian Mihailescu National University of Singapore, Singapore
ABSTRACT Structured peer-to-peer networks are scalable overlay network infrastructures that support Internet-scale network applications. A globally consistent peer-to-peer protocol maintains the structural properties of the network with peers dynamically joining, leaving and failing in the network. In this chapter, the authors discuss hierarchical distributed hash tables (DHT) as an approach to reduce the overhead of maintaining the overlay network. In a two-level hierarchical DHT, the top-level overlay consists of groups of nodes where each group is distinguished by a unique group identifier. In each group, one or more nodes are designated as supernodes and act as gateways to nodes at the second level. Collisions of groups occur when concurrent node joins result in the creation of multiple groups with the same group identifier. This has the adverse effects of increasing the lookup path length due to a larger top-level overlay, and the overhead of overlay network maintenance. We discuss two main approaches to address the group collision problem: collision detection-and-resolution, and collision avoidance. As an example, they describe an implementation of hierarchical DHT by extending Chord as the underlying overlay graph.
INTRODUCTION Structured peer-to-peer systems or distributed hash tables (DHT) are self-organizing distributed systems designed to support efficient and scalable lookups with dynamic network topology changes. Nodes are organized as structured overlay networks, and data is mapped to nodes in the overlap network based on their identifier. There are two main types of structured peer-to-peer architectures: flat and hierarchiDOI: 10.4018/978-1-60566-661-7.ch007
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Hierarchical Structured Peer-to-Peer Networks
cal. A flat DHT (Alima, 2003; Ratnasamy, 2001; Stoica, 2001; Rowstron, 2001; Maymounkov, 2002; Zhao, 2001) organizes nodes into one overlay network, in which each node has the same responsibility and uses the same rules for routing messages. On the other hand, a hierarchical DHT organizes nodes into a multi-level overlay network with the primary aim of reducing the maintenance overhead of its overlay network. In a peer-to-peer system, peers join and leave the system dynamically. A process called stabilization updates the routing information maintained in each peer so as to keep the overlay network up-to-date (Ghinita, 2006). A hierarchical DHT employs a multi-level overlay network where the top-level overlay consists of logical groups (Garcés-Erice, 2003; Harvey, 2003; Karger, 2004; Mislove, 2004; Tian, 2005; Xu, 2003; Zhao, 2003). Each group, which consists of a number of nodes, is assigned a group identifier with a specific objective such as improving administrative autonomy (Harvey, 2003; Mislove, 2004; Zhao, 2003), reducing network latency (Tian, 2005; Xu, 2003), and integrating various services into one system (Karger, 2004). Within a group, one or more nodes are selected as supernodes to act as gateways to nodes in the groups. Within each group, nodes can further form a second-level overlay network. In this chapter, we discuss the organization of a hierarchical DHT with the aim of reducing its overlay maintenance overhead. Using a two-level hierarchical Chord as an example, the top-level overlay network consists of groups with distinct group identifiers. However, collision of groups occurs when two or more groups are created with the same group identifier. Collisions increase stabilization overhead and degrade lookup performance. To address the collision problem, we discuss two main approaches: collision detection-and-resolution, and collision avoidance. The rest of this chapter is organized as follows. Section 2 presents an overview of flat DHT using Chord as the example (Stoica, 2001). Three main approaches to reduce routing maintenance overhead are introduced: hierarchical DHT, varying frequency of stabilizations, and varying number of routing states. Extending Chord into a hierarchical Chord DHT, Section 3 discusses two differing approaches in addressing the collision problem, namely, collision detection-and-resolution, and collision avoidance. Section 4 summarizes this chapter and discusses open issues.
DISTRIBUTED HASH TABLES Distributed hash table (Gummadi, 2003; Hsiao, 2003; Ratnasamy, 2002; Stribling, 2004) is a decentralized lookup scheme designed to provide scalable lookups, i.e., shorter lookup path length with high result guarantee and reduced number of false negative answers. The DHT protocol provides an interface to retrieve a key-value pair. A key is an identifier assigned to a resource; traditionally this key is a hash value associated with the resource. A value is an object to be stored into DHT; this could be the shared resource itself such as a file, an index or a pointer to a resource, or a resource metadata. An example of a key-value pair is <SHA1(file name), http://peer-id/file>, where the key is the SHA1 hash of the file’s name and the value is the address (location) of the file. To support scalable lookups with high result guarantee, DHT exploits the following: 1.
Key-to-node mapping: Assuming that keys and nodes share the same identifier space, DHT maps key k to node n where n is the node closest to k in the identifier space; we refer to n as the responsible node of k. The key-to-node mapping improves result guarantee because searching for a key-value pair equals to locating the node responsible for the key (Loo, 2004).
141
Hierarchical Structured Peer-to-Peer Networks
Figure 1. Chord lookup
2.
3.
Data-item distribution: Key-value pairs, also called data items, with key equals to k are stored at node n independent of the owners of these key-value pairs. This is implemented in DHT by a store operation (Dabel, 2003; Rhea, 2005). The concept of data-item distribution has been further exploited for various optimizations, including load balancing (Godfrey, 2004; Godfrey, 2005; Karger, 2004) and high availability (Dabek, 2001; Ghodsi, 2005a; Kubiatowicz, 2000; Landers, 2004; Leslie, 2006). Structured overlay network: Searching and storing a key-value pair requires routing of the request to a responsible node. To achieve scalable routing, nodes are organized as structured overlay network. A structured overlay network exhibits two main properties: (i) it resembles a graph and is organized into a network topology such as a ring (Rowstron, 2001; Stoica, 2001), a torus (Ratnasamy, 2001), or a tree (Aberer, 2003; Maymounkov, 2002), and (ii) each node uses its identifier to position itself in the structured overlay network. The tradeoff in different overlay topologies are routing performance and overhead of maintaining routing states.
As an example of DHT implementation, we discuss Chord which supports O(log N)-hop lookup path length and maintains O(log N) routing states per node, where N denotes the total number of nodes (Stoica, 2001). Chord organizes nodes as a ring that represents an m-bit one-dimensional circular identifier space, and as a consequence, all arithmetic is modulo 2m. To form a ring overlay, each node n maintains two pointers to its immediate neighbors as shown in Figure 1(a). The successor pointer points to successor(n), the immediate clockwise neighbor of n. Similarly, the predecessor pointer points to predecessor(n), the
142
Hierarchical Structured Peer-to-Peer Networks
Figure 2. Join operation in chord
immediate counter-clockwise neighbor of n. In Chord, every piece of data is assigned an m-bit identifier called a key. Key k is then map onto successor(k), the first node whose identifier is equal to or greater than k in the identifier space (Figure 1(b)). Thus, node n is responsible for keys in the range of (predecessor(n), n], i.e. keys that are greater than predecessor(n) but smaller than or equal to n. For example, node 32 is responsible for all keys in (21, 32]. All key-value pairs whose key equals to k are then stored on successor(k) regardless of who owns the key-value pairs. This distribution of keys is called data-item distribution. Finding key k implies that we route a request to successor(k). To achieve scalable routing, each node n maintains a finger table of m entries as shown in Figure 1(c). Each entry in this table is also called a finger. The ith finger of n is denoted as n.finger[i] and points to successor(n + 2i−1), where 1 ≤ i ≤ m. Note that the first finger is also the successor pointer while the largest finger divides the circular identifier space into two halves. When N < 2m, the finger table consists of only O(log N) unique entries (Stoica, 2001). By utilizing finger tables, Chord locates successor(k) in O(log N) hops with high probability (Stoica, 2001). Intuitively, the process resembles a binary search where each step halves the distance to successor(k). Thus, each node n forwards a request to the nearest known preceding node of k. This is repeated until the request arrives at predecessor(k), the node whose identifier precedes k, which will forward the request to successor(k). Figure 1(d) shows an example of finding successor(54) initiated by node 8. Node 8 forwards the request to its sixth finger which points to node 48. Node 48 is the predecessor of key 54 because its first finger points to node 56 and 48 < 54 ≤ 56. Finally, node 48 will forward the request to node 56. Figure 2 illustrates the construction of a Chord ring. A new node n joins a Chord ring by locating its own successor. Then, n inserts itself between successor(n) and the predecessor of successor(n), illustrated in Figure 2(a). The key-value pairs stored on successor(n), whose key is less than or equal to n, is migrated to node n (Figure 2(b)). Because the join operation invalidates the ring overlay, every node periodically invokes a maintenance process called stabilization to correct its successor and predecessor pointers (Figure 2(c)), and its remaining fingers. A number of approaches have been proposed to reduce the maintenance overhead of DHT. We classify these approaches into three main categories: hierarchical DHT, varying frequency of stabilizations, and varying number of routing states. The last two approaches are applicable directly to both flat and hierarchical DHTs.
143
Hierarchical Structured Peer-to-Peer Networks
HIERARCHICAL DHT In hierarchical DHT, nodes are organized as a two-level overlay network. The top-level overlay consists of logical groups of nodes, where each group is identified by a group identifier (gid). In each group, one or more nodes are designated as supernodes and act as gateways to the nodes at the second level. Each node is assigned an identifier consisting of two subfields: a unique node identifier as is common in DHT to distinguish different peers, and a group identifier to reflect the node’s group. For example, in compute-cycle sharing, a group identifier denotes the type of shared resource or processor type (March, 2007). Grouping of shared resources by processor types facilitates resource discovery and allocation. Figure 3 shows a hierarchical Chord system (Garcés-Erice, 2003), where nodes with the same gid form a group and the groups are organized in the top-level overlay network. Routing in the top-level and the second-level overlay are based on the group identifier and the node identifier, respectively. A hierarchical DHT groups nodes based on various properties to achieve specific objectives. Examples include: 1. 2. 3.
Grouping by administrative domains improves the administrative autonomy and reduces latency (Harvey, 2003; Mislove, 2004; Zhao, 2002); Grouping by physical proximity reduces network latency (Tian, 2005; Xu, 2003); Grouping by services promotes the integration of services into one system (Karger, 2004).
In terms of topology maintenance, the hierarchical structure has the following advantages compared to the flat structure: 1.
2.
Lower overhead of overlay maintenance: Maintenance of structured overlay network involves the correction of nodes’ routing states to adapt to dynamic events of node joining, leaving, or failing. Since the hierarchical structure partitions nodes into multiple overlays, each of which is smaller than a flat overlay, maintenance messages are routed only in one of these smaller overlays. This speeds up the correction of routing states while reducing the number of stabilization messages processed by each node. Isolation of churn: Topology changes within a group due to churn, i.e., continuous changes due to node joins, leaves, or failures, do not affect the top-level overlay or other groups. Stable overlay topologies improve the result guarantee of DHT lookups.
However, when new nodes join such a hierarchical DHT system, collisions of groups may occur. Collisions result in the top-level overlay containing two or more groups with the same group identifier, and increase the size of the overlay. For example, in a join operation, a new node firstly requests a bootstrap node to locate an existing group identified with gid. However, when the bootstrap node belongs to another group gid’ and some routing states in the top-level overlay are incorrect, the bootstrap node may fail to locate group gid. Thus, instead of joining group gid, the new node creates a new group with the same gid. Collisions increase the size of the top-level overlay, which in turn increases the lookup path length and the total number of stabilization messages. In the worst case, collisions lead to the degeneration of the hierarchical structure into the flat structure, where every node occupies the top-level overlay. If the number of groups is c times larger than the number of ideal groups1, the lookup path length is increased
144
Hierarchical Structured Peer-to-Peer Networks
Figure 3. Hierarchical structured chord
by O(log c) hops, but the total number of stabilization messages is increased by Ω(c) times. There are two main approaches to address the problem of collisions in hierarchical DHT systems: 1.
2.
Collision detection and resolution: With this approach, collisions are allowed to occur but it is the responsibility of the hierarchical DHT systems to detect collisions and merge these groups into a single group (March, 2005). In systems such as hierarchical Chord-based DHT (Garcés-Erice, 2003), Diminished Chord (Karger, 2004), Hieras (Xu, 2003) and HONet (Tian, 2005), collisions can occur but the problem is not directly addressed. They assume that collisions can be resolved by mechanisms inherent in the system structure, and the extent of collisions is not studied. Collision avoidance: In hierarchical DHT systems, schemes can be devised to ensure that collisions do not occur. This can be achieved through collision-free join protocols (Teo, 2008) or collision-free grouping policies (Harvey, 2003; Karger, 2004; Mislove, 2004; Xu, 2003; Zhao, 2003). Collision-free join protocol such as in (Teo, 2008) uses the predecessor node to serialize the join lookup operation. All nodes in the overlay network maintain accurate fingers and new groups are reflected instantaneously by the predecessor supernode. The leave protocol is also modified to ensure the correctness of the finger table, the successor pointers, and the predecessor pointers. Thus, a departing supernode notifies its successor and predecessor to update their pointers accordingly. As long as the fingers are maintained in an accurate state, collisions do not occur. ◦ In hierarchical DHT such as Brocade (Zhao, 2003), SkipNet (Harvey, 2003), and hierarchical Scribe (Mislove, 2004), collisions do not occur because a new node always chooses a bootstrap node from the same group. In such systems, nodes are grouped by their administrative domain. Therefore, it is natural for the new node to choose a bootstrap node from the same administrative domain. This grouping policy guarantees that multiple groups with the same group identifier are not created. However, such systems do not address other grouping policies that can introduce collisions, i.e., when a new node is bootstrapped from a node in
145
Hierarchical Structured Peer-to-Peer Networks
◦
a different group. In (Karger, 2004; Xu, 2003), all nodes in a group are assumed to be supernodes. Hence, collisions do not occur. However, the size of the top-level overlay, with or without collisions, is the same. In addition, the top-level overlay is larger than systems where only a subset of nodes becomes supernodes. Thus, the total number of stabilization messages is increased because more supernodes have to perform stabilization.
VARYING FREqUENCY OF STABILIzATION Frequency-based approaches such as adaptive stabilization (Castro, 2004; Ghinita, 2006), piggybacking stabilization with lookups (Alima, 2003; Li, 2005), and reactive stabilization (Alima, 2003) reduce the maintenance overhead by reducing the frequency in invoking routing-state correction procedures. Adaptive stabilization adjusts the frequency based on churn rate and the importance of each routing state to lookup performance2. Systems such as DKS (Alima, 2003) and Accordion (Li, 2005) piggyback stabilization with lookups to reduce the necessity of performing dedicated periodic stabilization; DKS refers to this as correction-on-use. Reactive stabilization such as DKS’s correction-on-change (Ghodsi, 2005) does away altogether with periodic stabilization. Instead, changes to overlay networks due to membership changes are propagated immediately when membership-change events are detected. However, Rhea et. al. reported that reactive stabilization can increase maintenance overhead under high churn rate and constrained bandwidth availability (Rhea, 2004). As an example, we discuss the stabilization mechanism in DKS (Distributed k-ary Search). DKS is proposed as a framework that generalizes different DHT implementations as a k-ary search, e.g., Chord is an instance of DKS when k = 2 (Alima, 2003). Rather than periodic stabilization, DKS maintains its overlay network based on three main principles: local atomic operations, correction-on-use, and correction-on-change. With the local atomic operations, DKS serializes concurrent node insertions/ leaves between two existing adjacent nodes. This reduces the number of incorrect successor and predecessor pointers during churn. However, the local atomic join does not correct other routing states such as fingers affected by the churn. These routing states will be corrected by correction-on-use and correction-on-change. The correction-on-use technique piggybacks stabilization during lookup processes. If the number of lookup messages is high, then the overlay network can be maintained without a need for dedicated stabilizations. Essentially, a routing table entry is not corrected until it is used during lookups. To realize correction-on-use, every lookup message contains information about the position of the receiver from the sender’s perspective3. If the receiver determines that the information (i.e. the sender’s perspective regarding the position of the receiver) is wrong, then the receiver advises the sender about the correct information (to the best of the receiver’s knowledge). The disadvantage of correction-on-use is that the speed at which the overlay network is corrected depends on the amount of lookup traffic. To address this disadvantage, DKS also employs correction-on-change: after a new node joins, it notifies all nodes that need to be updated.
146
Hierarchical Structured Peer-to-Peer Networks
VARYING SIzE OF ROUTING TABLES This approach reduces the size of routing tables so that the number of routing states to correct becomes smaller. Examples of DHT that implement this approach include CAN (Ratnasamy, 2001), Koorde (Kaashoek, 2003), and Accordion (Li, 2005). However, reducing the size of routing tables potentially increases lookup path length (Xu, 2003). In Accordion (Li, 2005), the size of routing tables is controlled through the process of acquisition and eviction of routing states. The rate of state acquisition is determined by a specified bandwidth budget, while the rate of state eviction is influenced by the churn rate. During acquisition, new states are added into a routing table. Accordion couples DKS’s correction-on-use approach with explicit stabilization. The frequency of explicit stabilization is constrained by the bandwidth budget. During eviction, node removes routing entries that point to nodes perceived to be non-existent. In addition, Accordion favors routing states that points to nodes with a longer live time; pointers to relative newer nodes have a higher probability to be evicted. Thus, a higher bandwidth budget increases routing-table size, whereas a higher churn rate reduces it. Besides reducing the size of routing tables, DHT can also partition each routing table into two parts: one part consisting of entries that are corrected through stabilization, and the other part consisting of cached entries. This reduces the maintenance overhead while achieving a shorter lookup path length. For example, in the latest implementation of Chord, a finger table consists of O(log N) fingers, and a number of location caches maintained by a LRU replacement policy (Stoica, 2001).
Hierarchical Chord A hierarchical Chord partitions its nodes into a multi-level overlay network. Because nodes join a smaller overlay network than in a flat structure, each node maintains and corrects a smaller number of routing states than in a flat structure. Figure 4 shows an example of hierarchical Chord. In hierarchical Chord, each node is assigned a group identifier (gid) and a unique node identifier (nid). We use the notation gid|nid to denote the group identifier and node identifier of each node. Nodes with the same gid form a group and groups are organized in the top-level as Chord overlay network. Within each group, nodes are organized as a second-level overlay using the node identifier. The topology and stabilization mechanism can differ from the top-level. In each group, one or more nodes designated as supernodes act as gateways to other nodes in the group. In Figure 4, node 0|5, node 2|7, node 4|2, and node 6|4 are respectively the supernodes of groups’ g0, g2, g4, and g6. In hierarchical Chord, a lookup request for key k implies locating the group responsible for k. Figure 5 illustrates the process. Firstly, a lookup request for key k is routed to the supernode of the initiating group. Secondly, using Chord lookup algorithm (Chord, 2001), the lookup request is further routed to the supernode of group whose group identifier is gid = successor(k). Thirdly, the lookup request can be further forwarded to one of the second-level nodes in group k based on additional criteria. As shown in Figure 5, a lookup request for key 2, initiated by second-level node 6|6, is forwarded to its supernode 6|4 (step 1). In the top-level overlay, the lookup request is routed to supernode 2|7 of group 2 (step 2). Finally, supernode 2|7 can further forward the request to its second-level nodes (step 3), e.g., lookup for compute resources of type 2 in multiple administrative domains (Teo, 2005). If new nodes join a hierarchical Chord when some routing states in the top-level overlay are incorrect, i.e., yet to be updated, then the top-level overlay may end up with two or more groups with the same
147
Hierarchical Structured Peer-to-Peer Networks
Figure 4. A two-level overlay network consisting of four groups
group identifier. This is called collisions of groups. In the following subsections, we discuss how collisions occur and present a collision detection and resolution scheme, and a collision avoidance scheme. To avoid sending additional overhead messages, collision detection is performed together with successor stabilization, i.e., the process of correcting successor pointers. This is because successful collision detections require the successor pointers in the top-level Chord overlay to be correct, and the correctness of the successor pointers is maintained by stabilization. In presenting our algorithm, we assume that each node maintains a list of variables shown in Table 1. The algorithm adopts the same convention as in (Stoica, 2001), where remote procedure calls or variables are preceded by the remote node identifier, while the local procedure calls and variables omit the local node identifier. Figure 5. Example of lookup in hierarchical chord
148
Hierarchical Structured Peer-to-Peer Networks
Table 1. Variables maintained by node n in hierarchical chord Variable
Description
gid
m-bit group identifier
nid
m-bit node identifier
successor
pointer to successor(gid) if n is a supernode, nil otherwise
predecessor
pointer to predecessor(gid) if n is a supernode, nil otherwise
is_super
true if n is a supernode, false otherwise
supernode
pointer to supernode of group gid if node is a supernode, nil othewise
COLLISIONS OF GROUP IDENTIFIERS Collisions of group identifiers arise because of join operations invoked by nodes. Figure 6 shows the nodejoin algorithm for hierarchical Chord. Node n, whose group identifier is denoted as n.gid, makes a request to join group g through bootstrap node n’. In a hierarchical Chord, this means finding successor(g|0) in the top-level overlay. If n’ successfully finds an existing group g then n joins this group using a groupspecific protocol (line 5–9). However, if n’ returns g’ > g, then n creates a new group with identifier g (line 11–15). A collision occurs if the new group is created even though a group with identifier g already exists. This happens when n and bootstrap node n’ are in two different groups, and the top-level overlay has not fully stabilized, i.e., some supernodes successor pointers are yet to be updated. Figure 7 illustrates a collision scenario when node 1|2 and node 1|3 belonging to the same group g1, join concurrently. Due to concurrent joins, find_successor() invoked by both nodes returns node 2|7. As a result, both the new node joins create two groups with the same group identifier g1. Collisions increase the maintenance overhead in the top-level Chord ring by Ω(c) times. Let K denotes the number of groups and N denotes the number of nodes. Assuming that each group assigns one supernode, the ideal size of the top-level overlay is K supernodes. Without collisions, the total number of stabilization messages is denoted as S. With collisions, the size of top-level overlay is increased by c times, i.e., cK groups. As each group performs periodic stabilization, the cost of stabilization with collisions (SC) is Ω(cS). The stabilization cost ratio, with and without collisions, is shown in Equation 1. Sc S
=
cK log2 cK c log2 cK = = W(c) K log2 K log2 cK
(1)
Collisions also increase the lookup path length in the top-level Chord by O(log c) hops. Without collisions, the top-level Chord ring consists of K supernodes, and hence, the lookup path length is O(log K). With collisions, the size of the top-level overlay becomes cK and the lookup path length is O(log cK) = O(log c + log K) hops.
149
Hierarchical Structured Peer-to-Peer Networks
Figure 6. Join operation
COLLISION DETECTION AND RESOLUTION SCHEME Collisions can be detected during successor stabilization. This is achieved by extending Chord’s stabilization so that it not only checks and corrects the successor pointer of supernode n, but also detects if n and its new successor should be in the same group. Figure 8 presents a collision detection algorithm. It first ensures that the successor pointer of a node is valid (line 4–5). It then checks for a potential collision
Figure 7. Collision at the top-level overlay
150
Hierarchical Structured Peer-to-Peer Networks
Figure 8. Collision detection algorithm
(line 8–10), before updating the successor pointer to point to the correct node (line 11–13). Figure 9 illustrates the collision detection process. In Figure 9(a), a collision occurs when nodes 1|2 and 1|3 belonging to the same group, group 1, join concurrently. In Figure 9(b), node 1|3 stabilizes and causes node 2|7 to set its predecessor pointer to node 1|3 (step 1). Then, the stabilization by node 0|5 causes 0|5 to set its successor pointer to node 1|3 (step 2), and node 1|3 to set its predecessor pointer
151
Hierarchical Structured Peer-to-Peer Networks
Figure 9. Collision detection piggybacks successor stabilization
to node 0|5 (step 3). In Figure 9(c), the stabilization by node 1|2 causes 1|2 to set its successor pointer to node 1|3. At this time, a collision is detected by node 1|2 and is resolved by merging 1|2 to 1|3. If each group contains more than one supernode, then the is_collision routine shown in Figure 8 may incorrectly detect collisions. Consider the example in Figure 10(a). When node n stabilizes, it incorrectly detects a collision with node n’ because n.successor.predecessor = n’ and n.gid = n’.gid. An approach to avoid this problem is for each group to maintain a set of its supernodes (Garcés-Erice, 2003; Gupta, 2003) so that each supernode can accurately decide whether a collision has occurred. The modified collision detection algorithm is shown in Figure 10(b). To resolve collisions, groups associated with the same gid are merged. After the merging, some supernodes, depending on the group policy, become ordinary nodes. Before a supernode changes its state into a second-level node, the supernode notifies its successors and predecessors to update their pointers (see Figure 11). Nodes in the second level also need to be merged to the new group. We discuss two methods to merge groups, namely supernode initiated and node initiated.
152
Hierarchical Structured Peer-to-Peer Networks
Figure 10. Collision detection for groups with several supernodes
Supernode Initiated To merge two groups n.gid and n’.gid, supernode n notifies its second-level nodes to join group n’.gid (Figure 12). The advantage of this approach is that second-level nodes join a new group as soon as a collision is detected. However, n needs to keep track of its group membership. If n has only partial knowledge of group membership, some nodes in the second-level can become orphans.
Figure 11. Announce leave to preceding and succeeding supernodes
153
Hierarchical Structured Peer-to-Peer Networks
Figure 12. Collision resolution-supernode-initiated approach
Node Initiated In node-initiated merging, each second-level node periodically checks that its known supernode n’ is still a valid supernode (Figure 13). If n’ is no longer a supernode, then the second-level node will ask n’ to find the correct supernode. These second-level nodes then join a new group through the new supernode. This approach does not require supernodes to track group membership. However, it introduces an additional overhead to the second-level nodes as they periodically check the status of their supernode.
COLLISION AVOIDANCE SCHEME Avoiding collision has the following advantages: 1. 2. 3. 4.
154
lower overhead: Runaway collisions are very costly, and detecting and resolving collisions is highly difficult in a decentralized and dynamic peer-to-peer system with high churn rate (Teo, 2008); reduced bootstrap time: New peers can join the network at a faster rate because the time between the join event and the update of the underlying overlay network states is reduced; improved lookup performance: Without collision, the top-level overlay is maintained at the ideal size; faster resource availability: As costly collision resolution is not necessary, resources are available once the nodes join the network.
Hierarchical Structured Peer-to-Peer Networks
Figure 13. Collision resolution-node-initiated approach
In the join operation in Figure 6, a node performs a lookup for the group identifier, which is handled by the supernode of the successor group. If the joining node and the supernode that respond to the lookup have the same group identifier, the node joins the second-level overlay. Collisions occur when concurrent joins create multiple new groups with the same group identifier in the first-level overlay. This scenario arises because before the routing states are updated, each joining node is unaware of the existence of other joining nodes. To avoid collisions due to join requests, the join protocol is modified such that the predecessor node handles the join lookup request instead of the successor node. The rationale behind this change is that all join requests are serialized at the predecessor. If the group identifier of the successor’s supernode is different from the group identifier of the joining node, then the predecessor immediately changes its successor pointer to reflect the new group created by the joining node. Thus, this modification allows the overlay network to reveal new groups to subsequent joining nodes and make them available to incoming lookups.
155
Hierarchical Structured Peer-to-Peer Networks
Figure 14. Collision-free join operation
Join Protocol The detailed join algorithm shown in Figure 14 is divided into the following steps: 1. 2. 3.
4.
156
A joining node performs a lookup for group gid, which is routed at the top overlay to the supernode whose identifier is successor(gid|0) (line 3). If a group for the resource type exists, a supernode is already created for the resource type and the joining node becomes a member of the second-level overlay (lines 5–7). If a group for the resource type does not exist, the joining node becomes the supernode of a newly created group. The joining node then sets its predecessor and successor pointers accordingly (lines 9–11). In addition, the supernode in step 1 updates its successor pointer to the joining node. Stabilization is used by the new supernode to build a finger table (line 12).
Hierarchical Structured Peer-to-Peer Networks
Figure 15. Leave operation
Leave Protocol When a supernode leaves its group becomes an orphan group if the supernode is the only one in the group. If a new node attempts to join the orphan group, then a collision occurs because the new node cannot locate the orphan group in the top-level overlay. Hence, a new group is created in the top-level overlay where its group identifier is the same as the orphan group. To prevent this type of collisions, the departing supernode notifies its first-level overlay successor and predecessor to update their finger tables. Furthermore, a new supernode needs to be elected for the orphan group to prevent collisions during subsequent node joins. Figure 15 presents a simple-but-costly leave protocol that reuses our collision-free join operation (Figure 14) to elect new supernodes. In this protocol, the orphan group is disbanded where all its members are forced to rejoin the system. Thus, the node which completes its join operation first becomes the new supernode.
Failures A more complex case which leads to collisions is when supernodes fail. A supernode failure invalidates other nodes’ successor pointers and finger table. While inaccurate finger table only degrade lookup performance, inaccurate successor pointers leads to collisions. However, avoiding collisions due to supernode failures is a challenging problem. Unlike departures (Section 3.3.2) where supernodes leave the overlay network gracefully, failures can be viewed as supernodes leave the overlay network silently. This means that there is no notification to the overlay network to indicate that any collision avoidance procedures should be triggered. Hence, it is necessary for the system to detect the presence of supernode failures so that any corrective measures can be initiated, e.g. the collision detection-and-resolution
157
Hierarchical Structured Peer-to-Peer Networks
scheme presented in Section 3.2.
SUMMARY AND OPEN ISSUES Efficient lookup is an essential service in peer-to-peer applications. In structured peer-to-peer systems, dynamic joining and leaving of peers and failing of peer nodes change the structural properties of the overlay network. Stabilization, the process of overlay network maintenance is a necessary overhead and impact on the lookup performance. In this chapter, we discuss three main approaches in reducing overlay maintenance overhead, namely, hierarchical DHT, varying frequency of stabilizations and varying number of routing states. We discuss in more detail hierarchical DHT where nodes are organized as multi-level overlay networks. In hierarchical DHT, collisions of groups occur when concurrent node joins result in multiple groups with the same group identifier being created at the top-level overlay. Collisions increase the size of the top-level overlay by a factor c, which increases the lookup path length by only O(log c) hops, but increases the total number of stabilization messages by Ω(c) times. To address the collision problem, we present firstly a collision detection-and-resolution scheme and two approaches to merge collision groups, namely, supernode-initiated and node-initiated. Though the effect of collisions can be reduced by collision detection and correction, the message overhead cost is high. A collision avoidance scheme where join and leave operations are collision free is discussed. The open issues of group collisions in hierarchical DHT include: 1.
2.
3.
158
Current experimental results on both collision detection-and-resolution and avoidance schemes assume that node joins, leaves, and fails occur exclusively (March, 2005; Teo, 2008). However, in practice, these three events are interleaved and are important when network churn rate is high. Thus, in addition to the frequency of top-level overlay’s stabilizations during collision detections (March, 2005), churn also impacts how often second-level nodes should check the status of their supernode during the node-initiated collision resolution approach. An adaptive method similar to (Ghinita, 2006) is a possible direction; however, this has not been studied in detail. When a supernode leaves, the current collision-free leave protocol uses a simple but naïve approach to deal with orphan groups where all the second-level nodes are forced to rejoin a hierarchical DHT. A more efficient approach is required. For example, an efficient distributed election scheme can be used to select a supernode among the second-level nodes, and only the elected supernode joins the top-level overlay. Node failures are unplanned and collisions that arise due to node failure are therefore harder to address. Avoiding collisions due to supernode failures is a challenge. We envisage two possible solutions; both using multiple supernodes. Firstly, each group employs a number of backup supernodes so that the collision-free join protocol is able to resolve the problem of orphan group before redirecting new nodes to the group. Alternatively, each group can have multiple supernodes in the top-level overlay; but this is at the expense of a larger top-level overlay.
Hierarchical Structured Peer-to-Peer Networks
REFERENCES Aberer, K., Cudr-Mauroux, P., Datta, A., Despotovic, Z., Hauswirth, M., & Punceva, M. (2003). P-Grid: A self-organizing structured p2p system. SIGMOD Record, 32(3), 29–33. doi:10.1145/945721.945729 Alima, L. O., El-Ansary, S., Brand, P., & Haridi, S. (2003). DKS (N, k, f): A Family of Low Communication, Scalable and Fault-tolerant Infrastructures for P2P Applications. In Proceedings of the 3rd IEEE Intl. Symp. on Cluster Computing and the Grid (pp. 344-350). New York: IEEE Computer Society Press. Androutsellis-Theotokis, S., & Spinellis, D. (2004). A survey of peer-to-peer content distribution technologies. ACM Computing Surveys, 36(4), 335–371. doi:10.1145/1041680.1041681 Castro, M., Costa, M., & Rowstron, A. (2004). Performance and Dependability of Structured Peer-toPeer Overlays. In Proceedings of the 2004 Intl. Conf. on Dependable Systems and Networks (pp. 9-18). New York: IEEE Computer Society Press. Dabek, F., Kaashoek, M. F., Karger, D., Morris, R., & Stoica, I. (2001). Wide-Area Cooperative Storage with CFS. In Proceedings of the 11th ACM Symp. on Operating Systems Principles (pp. 202-215). New York: ACM Press. Dabek, F., Zhao, B. Y., Druschel, P., Kubiatowicz, J., & Stoica, I. (2003). Towards a Common API for Structured Peer-to-Peer Overlays. In Proceedings of the 2nd Intl. Workshop on Peer-to-Peer Systems (pp. 33-44). Berlin: Springer-Verlag. Garcés-Erice, L., Biersack, E. W., Felber, P. A., Ross, K. W., & Urvoy-Keller, G. (2003). Hierarchical Peer-to-Peer Systems. In Proceedings of the 9th Intl. Euro-Par Conf. (pp. 1230-1239). Berlin: SpringerVerlag. Ghinita, G., & Teo, Y. M. (2006). An adaptive stabilization framework for distributed hash tables. In Proceedings of the 20th IEEE Intl. Parallel and Distributed Processing Symp. New York: IEEE Computer Society Press. Ghodsi, A., Alima, L. O., & Haridi, S. (2005). Low-bandwidth topology maintenance for robustness in structured overlay networks. In Proceedings of 38th Hawaii Intl. Conf. on System Sciences (p. 302). New York: IEEE Computer Society Press. Ghodsi, A., Alima, L. O., & Haridi, S. (2005a). Symmetric replication for structured peer-to-peer systems. In Proceedings of the 3rd Intl. Workshop on Databases, Information Systems and Peer-to-Peer Computing (p. 12). Berlin: Spinger-Verlag. Godfrey, B., Lakshminarayanan, K., Surana, S., Karp, R., & Stoica, I. (2004). Load balancing in dynamic structured p2p systems. In Proceedings of INFOCOM (pp. 2253- 2262). New York: IEEE Press. Godfrey, P. B., & Stoica, I. (2005). Heterogeneity and load balance in distributed hash tables. In Proceedings of INFOCOM (pp. 596-606). New York: IEEE Press. Gummadi, K., Gummadi, R., Gribble, S., Ratnasamy, S., Shenker, S., & Stoica, I. (2003). The impact of dht routing geometry on resilience and proximity. In Proceedings of ACM SIGCOMM (pp. 381-394). New York: ACM Press.
159
Hierarchical Structured Peer-to-Peer Networks
Gupta, I., Birman, K., Linga, P., Demers, A., & Renesse, R. V. (2003). Kelips: Building an efficient and stable P2P DHT through increased memory and background overhead. In Proceedings of the 2nd Intl. Workshop on Peer-to-Peer Systems (pp. 160-169). Berlin: Springer-Verlag. Harvey, N. J., Jones, M. B., Saroiu, S., Theimer, M., & Wolman, A. (2003). SkipNet: A scalable overlay network with practical locality properties. In Proceedings of the 4th USENIX Symp. on Internet Technologies and Systems (pp. 113-126). USENIX Association. Hsiao, H.-C., & King, C.-T. (2003). A tree model for structured peer-to-peer protocols. In Proceedings of the 3rd IEEE Intl. Symp. on Cluster Computing and the Grid (pp. 336-343). New York: IEEE Computer Society Press. Kaashoek, M. F., & Karger, D. R. (2003). Koorde: A simple degree-optimal distributed hash table. In Proceedings of the 2nd Intl. Workshop on Peer-to-Peer Systems (pp. 98-107). Berlin: Springer-Verlag. Karger, D. R., & Ruhl, M. (2004). Diminished chord: A protocol for heterogeneous subgroup. In Proceedings of the 3rd Intl. Workshop on Peer-to-Peer Systems (pp. 288-297). Berlin: Springer-Verlag. Karger, D. R., & Ruhl, M. (2004). Simple, efficient load balancing algorithms for peer-to-peer systems. In Proceedings of the 3rd Intl. Workshop on Peer-to-Peer Systems (pp. 131-140). Berlin: SpringerVerlag. Kubiatowicz, J., Bindel, D., Chen, Y., Eaton, P., Geels, D., Gummadi, R., et al. (2000). OceanStore: An Architecture for Global-Scale Persistent Storage. In Proceedings of the 9th Intl. Conf. on Architectural Support for Programming Languages and Operating Systems (pp. 190-201). New York: ACM Press. Landers, M., Zhang, H., & Tan, K.-L. (2004). PeerStore: Better performance by relaxing in peer-to-peer backup. In Proceedings of the 4th Intl. Conf. on Peer-to-Peer Computing (pp. 72-79). New York: IEEE Computer Society Press. Leslie, M., Davies, J., & Huffman, T. (2006). replication strategies for reliable decentralised storage. In Proceedings of the 1st Workshop on Dependable and Sustainable Peer-to-Peer Systems (pp. 740-747). New York: IEEE Computer Society Press. Li, J., Stribling, J., Gil, T. M., Morris, R., & Kaashoek, M. F. (2004). Comparing the performance of distributed hash tables under churn. In Proceedings of the 3rd Intl. Workshop on Peer-to-Peer Systems (pp. 87-99). Berlin: Springer-Verlag. Li, J., Stribling, J., Morris, R., & Kaashoek, M. F. (2005). Bandwidth-efficient management of dht routing tables. In Proceedings of 2nd Symp. on Networked Systems Design and Implementation (pp. 99-114). USENIX Association. Loo, B. T., Huebsch, R., Stoica, I., & Hellerstein, J. M. (2004). The case for a hybrid p2p search infrastructure. In Proceedings of the 3rd Intl. Workshop on Peer-to-Peer Systems (pp. 141-150). Berlin: Springer-Verlag. March, V., Teo, Y. M., Lim, H. B., Eriksson, P., & Ayani, R. (2005). Collision detection and resolution in hierarchical peer-to-peer systems. In Proceedings of the 30th IEEE Conf. on Local Computer Networks (pp. 2-9). New York: IEEE Computer Society Press.
160
Hierarchical Structured Peer-to-Peer Networks
March, V., Teo, Y. M., & Wang, X. (2007). DGRID: A DHT-based resource indexing and discovery scheme for computational grids. In Proceedings of the 5th Australasian Symp. on Grid Computing and e-Research (pp. 41-48). Australian Computer Society, Inc. Maymounkov, P., & Mazieres, D. (2002). Kademlia: A peer-to-peer information system based on the XOR metric. In Proceedings of the 1st Intl. Workshop on Peer-to-Peer Systems (pp. 53-65). Berlin: Springer-Verlag. Mislove, A., & Druschel, P. (2004). Providing administrative control and autonomy in structured peerto-peer overlays. Proceedings of the 3rd Intl. Workshop on Peer-to-Peer Systems (pp. 162-172). Berlin: Springer-Verlag. Oram, A. (2001). Peer-to-Peer: Harnessing the power of disruptive technologies. O’Reilly. Rao, A., Lakshminarayanan, K., Surana, S., Karp, R., & Stoica, I. (2003). Load Balancing in structured P2P systems. Proceedings of the 2nd Intl. Workshop on Peer-to-Peer Systems (pp. 68-79). Berlin: Springer-Verlag. Ratnasamy, S., Francis, P., Handley, M., Karp, R., & Shenker, S. (2001). A scalable content-addressable network. Proceedings of ACM SIGCOMM (pp. 161-172). New York: ACM Press. Ratnasamy, S., Stoica, I., & Shenker, S. (2002). Routing algorithms for DHTs: Some open questions. Proceedings the 1st Intl. Workshop on Peer-to-Peer Systems (pp. 45-52). Berlin: Springer-Verlag. Rhea, S., Geels, D., Roscoe, T., & Kubiatowicz, J. (2004). Handling Churn in a DHT. Proceedings of the USENIX (pp. 127-140). USENIX Association. Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., et al. (2005). OpenDHT: A public DHT service and its uses. In Proceedings of ACM SIGCOMM (pp. 73-84). New York: ACM Press. Rowstron, A., & Druschel, P. (2001). Pastry: Scalable, distributed object location and routing for largescale peer-to-peer systems. In Proceedings of IFIP/ACM Intl. Conf. on Distributed Systems Platforms (pp. 329-350). Berlin: Springer-Verlag. Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., & Balakrishnan, H. (2001). Chord: A scalable peerto-peer lookup service for Internet applications. In Proceedings of ACM SIGCOMM (pp. 149-160). New York: ACM Press. Teo, Y. M., & Mihailescu, M. (2008). Collision avoidance in hierarchical peer-to-peer systems. In Proceedings of 7th Intl. Conf. on Networking (pp. 336-341). New York: IEEE Computer Society Press. Tian, R., Xiong, Y., Zhang, Q., Li, B., Zhao, B. Y., & Li, X. (2005). Hybrid Overlay Structure Based on Random Walks. In Proceedings of the 4th Intl. Workshop on Peer-to-Peer Systems (pp. 152-162). Berlin: Springer-Verlag. Xu, J. (2003). On the fundamental tradeoffs between routing table size and network diameter in peerto-peer networks. In Proceedings of INFOCOM (pp. 2177-2187). New York: IEEE Press.
161
Hierarchical Structured Peer-to-Peer Networks
Xu, Z., Min, R., & Hu, Y. (2003). HIERAS: A DHT based hierarchical p2p routing algorithm. In Proceedings of the 2003 Intl. Conf. on Parallel Processing (pp. 187-194). New York: IEEE Computer Society Press. Zhao, B. Y., Duan, Y., Huang, L., Joseph, A., & Kubiatowicz, J. (2003). Brocade: landmark routing on overlay networks. In Proceedings of the 2nd Intl. Workshop on Peer-to-Peer Systems (pp. 34-44). Berlin: Springer-Verlag. Zhao, B. Y., Kubiatowicz, J., & Joseph, A. D. (2001). Tapestry: An infrastructure for fault-tolerant widearea location and routing, (Tech. Rep.). UC Berkeley, Computer Science Department, Berkeley, CA.
KEY TERMS AND DEFINITIONS Chord: A structured overlay network with nodes organized as a logical ring. Churn: Changes in overlay networks due to dynamic node joins, leaves, or failures. Collision of Groups: An occurrence when two or more groups with the same group identifier occupy the top-level overlay network. Distributed Hash Table: A class of distributed systems where keys are map onto nodes and nodes are organized as a structured overlay network to support scalable lookup service. Finger: An entry in each node’s routing table (finger table) in Chord Key-Value Pair: A tuple consisting of a unique identifier (key) and an object (value) to be stored into DHT. Predecessor: The immediate counter-clockwise neighbor of a node in Chord. Successor: The immediate clockwise neighbor of a node in Chord. Supernode: A gateway node to a second-level hierarchical overlay network. Stabilization: A procedure to keep the routing information in each peer nodes updated.
ENDNOTES 1 2
3
162
Size of the top-level overlay without collision. Routing states with higher importance such as successor pointers in Chord (Stoica, 2001) and leaf sets in Pastry (Rowstron, 2001), are refreshed/corrected more frequently. This is possible due to the k-ary model.
163
Chapter 8
Load Balancing in Peerto-Peer Systems Haiying Shen University of Arkansas, USA
ABSTRACT Structured peer-to-peer (P2P) overlay networks like Distributed Hash Tables (DHTs) map data items to the network based on a consistent hashing function. Such mapping for data distribution has an inherent load balance problem. Thus, a load balancing mechanism is an indispensable part of a structured P2P overlay network for high performance. The rapid development of P2P systems has posed challenges in load balancing due to their features characterized by large scale, heterogeneity, dynamism, and proximity. An efficient load balancing method should flexible and resilient enough to deal with these characteristics. This chapter will first introduce the P2P systems and the load balancing in P2P systems. It then introduces the current technologies for load balancing in P2P systems, and provides a case study of a dynamism-resilient and proximity-aware load balancing mechanism. Finally, it indicates the future and emerging trends of load balancing, and concludes the chapter.
1. INTRODUCTION Peer-to-peer (P2P) overlay network is a logical network on top of a physical network in which peers are organized without any centralized coordination. Each peer has equivalent responsibilities, and offers both client and server functionalities to the network for resource sharing. Over the past years, the immense popularity of P2P resource sharing services has produced a significant stimulus to contentdelivery overlay network research (Xu, 2005). An important class of the overlay networks is structured P2P overlays, i.e. distributed hash tables (DHTs), that map keys to the nodes of a network based on a consistent hashing function (Karger, 1997). Representatives of the DHTs include CAN (Ratnasamy, DOI: 10.4018/978-1-60566-661-7.ch008
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Load Balancing in Peer-to-Peer Systems
2001), Chord (Stoica, 2003), Pastry (Rowstron, 2001), Tapestry (Zhao, 2001), Kademlia (Maymounkov, 2002), and Cycloid (Shen, 2006); see (Shen, 2007) and references therein for the details of the representatives of the DHTs. In a DHT overlay, each node and key has a unique ID, and each key is mapped to a node according to the DHT definition. The ID space of each DHT is partitioned among the nodes and each node is responsible for those keys the IDs of which are located in its space range. For example, in Chord, a key is stored in a node whose ID is equal to or succeeding the key’s ID. However, a downside of consistent hashing is uneven load distribution. In theory, consistent hashing produces a bound of O(log n) imbalance of keys between nodes, where n is the number of nodes in the system (Karger, 1997). Load balancing is an indispensable part of DHTs. The objective of load balancing is to prevent nodes from being overloaded by distributing application load among the nodes in proportion to their capacities. Although the load balancing problem has been studied extensively in a general context of parallel and distributed systems, the rapid development of P2P systems has posed challenges in load balancing due to their features characterized by large scale, heterogeneity, dynamism/churn, and proximity. An efficient load balancing method should flexible and resilient enough to deal with these characteristics. Network churn represents a situation where a large percentage of nodes and items join, leave and fail continuously and rapidly, leading to unpredicted P2P network size. Effective load balancing algorithms should work for DHTs with and without churn and meanwhile be capable of exploiting the physical proximity of the network nodes to minimize operation cost. By proximity, we mean that the logical proximity abstraction derived from DHTs don’t necessarily match the physical proximity information in reality. In the past, numerous load balancing algorithms were proposed with different characteristics (Stoica, 2003; Rao, 2003; Godfrey, 2006; Zhu, 2005; Karger, 2006). This chapter is dedicated to providing the reader with a complete understanding of load balancing in P2P overlays. The rest of this chapter is organized as follows. In Section 2, we will give an in depth background of load balancing algorithms in P2P overlays. We move on to present the load balancing algorithms discussing their goals, properties, initialization, and classification in Section 3. Also, we will present a case study of a dynamism-resilient and locality-aware load balancing algorithm. In Section 4, we will discuss the future and emerging trends in the domain of load balancing, and present the current open problems in load balancing from the P2P overlay network perspective. Finally, in Section 5 we conclude this chapter.
2. BACKGROUND Over the past years, the immerse popularity of the Internet has produced a significant stimulus to P2P file sharing systems. A recent study of large scale characterization of traffic (Saroiu, 2002) shows that more than 75% of Internet traffic is generated by P2P applications. Load balancing is an inherent problem in DHTs based on consistent hashing functions. Karger et al. proved that the consistent hashing function in Chord (Karger, 1997) leads to a bound of O(log n) imbalance of keys between the nodes. Load imbalance adversely affects system performance by overloading some nodes, while prevents a P2P overlay from taking full advantage of all resources. One main goal of P2P overlays is to harness all available resources such as CPU, storage, and bandwidth in the P2P network so that users can efficiently and effectively access files. Therefore, load balancing is crucial to achieving high performance of a P2P overlay. It helps to avoid overloading nodes and make full use of all available resources in the P2P overlay.
164
Load Balancing in Peer-to-Peer Systems
Load balancing in DHT networks remains challenging because of their two unique features: 1.
2.
Dynamism. A defining characteristic of DHT networks is dynamism/churn. A great number of nodes join, leave and fail continually and rapidly, leading to unpredicted network size. A load balancing solution should be able to deal with the effect of churn. Popularity of the items may also change over time. A load balancing solution that works for static situations does not necessarily guarantee a good performance in dynamic scenarios. Skewed query patterns may also result in considerable number of visits at hot spots, hindering efficient item access. Proximity. A load balancing solution tends to utilize proximity information to reduce the load balancing overhead. However, logical proximity abstraction derived from DHTs doesn’t necessarily match the physical proximity information in reality. This mismatch becomes a big obstacle for the deployment and performance optimization of P2P applications.
In addition, DHT networks are often highly heterogeneous. With the increasing emergence of diversified end devices on the Internet equipped with various computing, networking, and storage capabilities, the heterogeneity of participating peers of a practical P2P system is pervasive. This requires a load balancing solution to distribute not only the application load (e.g. file size, access volume), but also the load balancing overhead among the nodes in proportion to their capacities. Recently, numerous load balancing methods have been proposed. The methods can be classified into three categories: virtual server, load transfer and ID assignment or reassignment. Virtual server methods (Stoica, 2003; Godfrey, 2005) map keys to virtual servers the number of which is much more than real servers. Each real node runs a number of virtual servers, so that each real node is responsible for O(1/n) of the key ID space with high probability. Load transfer methods (Rao, 2003; Karger, 2004; Zhu, 2005) move load from heavily loaded nodes to lightly loaded nodes to achieve load balance. ID assignment or reassignment methods (Bienkowski, 2005; Byers, 2003) assign a key to a lightly loaded node among a number of options, or reassign a key from a heavily loaded node to a lightly loaded node.
3. LOAD BALANCING METHODS 3.1 Examples of Load Balancing Methods In this section we will review various load balancing methods that have been proposed for structured P2P overlays over the last few years. For each method, we will review its goals, algorithms, properties, and pros and cons.
3.1.1 Virtual Server Basic virtual server method. Consistent hashing leads to a bound of O(log n) imbalance of keys between nodes. Karger et al. (Karger, 1997) pointed out that the O(log n) can be reduced to an arbitrarily small constant by having each node run (log n) virtual nodes, each with its own identifier. If each real node runs v virtual nodes, all bounds should be multiplied by v. Based on this principle, Stoica et al. (2003) proposed an abstraction of virtual servers for load balancing in Chord. With the virtual server method, Chord makes the number of keys per node more uniform by associating keys with virtual nodes, and map-
165
Load Balancing in Peer-to-Peer Systems
ping multiple virtual nodes (with unrelated identifiers) to each real node. This provides a more uniform coverage of the identifier space. For example, if (log n) randomly chosen virtual nodes are allocated to each real node, with high probability each of the n bins will contain O(log n) virtual nodes (Motwani, 1995). The virtual server-based approach for load balancing is simple in concept. There is no need for the change of underlying DHTs. However, the abstraction incurs large space overhead and compromises lookup efficiency. The storage for each real server increases from O(log n) to O(log2 n) and the network traffic increase considerably by a factor of Ω(log n). In addition, node joins and departures generate high overhead for nodes to update their routing tables. This abstraction of virtual server simplifies the treatment of load balancing problem at the cost of higher space overhead and lookup efficiency compromise. Moreover, the original concept of virtual server ignores the node heterogeneity. Y0 DHT protocol. Brighten et al. (Godfrey, 2005) addressed the problem of virtual server method by arranging a real server for virtual ID space of consecutive virtual IDs. This reduces the load imbalance from O(log n) to a constant factor. The authors developed a DHT protocol based on Chord, called Y0, that achieves load balancing with minimal overhead under the assumption that the load is uniformly distributed in the ID space. The authors proved that Y0 can achieve near-optimal load balancing with low overhead, and it increases the size of the routing tables by at most a constant factor. Y0 is based on the concept of virtual servers, but with a twist: instead of picking k virtual servers with random IDs, a node clusters those IDs in a random fraction Θ(k/n) of the ID space. This allows the node to share a single set of overlay links among all k virtual servers. As a result, the number of links per physical node is still Θ(log n), even with Θ(log n) virtual servers per physical node. To deal with node heterogeneity, Y0 arranges higher-capacity nodes to have a denser set of overlay links, and allows lower-capacity nodes to be less involved in routing. It results in reduced lookup path length compared to the homogeneous case in which all nodes have the same number of overlay links. Y0 leads to more significant than Chord with the original concept of virtual server, because its placement of virtual servers provides more control over the topology. Real-world simulation results show that Y0 reduces the load imbalance of Chord from O(log n) to a less than 3.6 without increasing the number of links per node. In addition, the average path length is significantly reduced as node capacities become increasingly heterogeneous. For a real-word distribution of node capacities, the path length in Y0 is asymptotically less than half the path length in the case of a homogeneous system. Y0 operates under the uniform load assumption that the load of each node is proportional to the size of the ID space it owns. This is reasonable when all objects generate similar load (e.g., have the same size), the object IDs are randomly chosen (e.g., are computed as a hash of the object’s content), and the number of objects is large compared to the number of nodes (e.g., Ω(n log n)). However, some of the cases may not hold true in reality. Virtual node activation. In virtual server methods, to maintain connectivity of the network, every virtual node needs to periodically check its neighbors to ensure their updated status. More virtual nodes will lead to higher overhead for neighbor maintenance. Karger and Ruhl (Karger, 2004) coped with the virtual server problem by arranging for each real node to activate only one of its O(log n) virtual servers at any given time. The real node occasionally checks its inactive virtual servers and may migrate to one of them if the distribution of load in the system has changed. Since only one virtual node is active, the overhead for neighbor information storage and neighbor maintenance will not be increased in a real node. As in the Chord with the original virtual server method, this scheme gives each real node a small number of addresses on the Chord ring, preserving Chord’s protection against address spoofing by malicious
166
Load Balancing in Peer-to-Peer Systems
nodes trying to disrupt the routing layer. Combining the virtual node activation load-balancing scheme with the Koorde routing protocol (Kaashoek, 2003), the authors got a protocol that simultaneously offers (i) O(log n) degree per real node, (ii) O(log n/log log n) lookup hops, and (iii) constant factor load balance. The authors claimed that previous protocols could achieve any two of these but not all three. Generally speaking, achieving (iii) required operating O(log n) virtual nodes, which pushed the degree to O(log2 n) and failed to achieve (i).
3.1.2 ID Assignment or Reassignment In this category of load balancing methods, most proposals are similar in that they consider a number of (typically, Θ(log n)) locations for a node and select the one which gives the best load balance. The proposals differ in which locations should be considered, and when the selection should be conducted (Godfrey, 2005). Some proposals arrange a newly-jointed node to select a location, while others let nodes re-select a location when a node is overloaded. Naor and Weider (2003) proposed a method in which a node checks Θ(log n) random IDs when joining, and chooses the ID which leads to the best load balance. They show that this method produces a maximum share of 2 if there are no node deletions. Share is an important metric for evaluating the performance of a load balancing method (Godfrey, 2005). Node v’s share is defined as: share(v ) =
fv cv n
,
where fv is the ID space assigned to node v, and cv is the normalized capacity of node v such that the average capacity is 1 and å v cv = n . To handle load imbalance incurred by node departures, nodes are divided into groups of Θ(log n) nodes and periodically reposition themselves in each group. Adler et al. (Adler, 2003) proposed to let a joining node randomly contacts an existing node already in the DHT. The joining node then chooses an ID in the longest interval owned by one of the proposed node’s O(log n) neighbors to divide the interval into half. As a result, the intervals owned by nodes have almost the same length, leading to an O(1) maximum share. Manku (Manku, 2004) proposed a load balancing algorithm. In the algorithm, a newly-joined node randomly chooses a node and splits in half the largest interval owned by one of the Θ(log n) nodes adjacent to the chosen node in the ID space. This achieves a maximum share of 2 while moving at most one node ID for each node arrival or departure. It extends to balancing within a factor 1 + ε but moves Θ (1/ε) IDs for any ε>0. As mentioned that Karger and Ruhl (Karger, 2004) proposed an algorithm in which each node has O(log n) virtual nodes, i.e. IDs, and periodically selects an ID among them as an active ID. This has maximum share 2 + ε, but requires reassignment of O(log log n) IDs per arrival or departure. Bienkowski et al. (2005) proposed a node departure and re-join strategy to balance the key ID intervals across the nodes. In the algorithm, lightly loaded nodes leave the system and rejoin the system with a new ID to share the load of heavily loaded ones. The strategy reduces the number of reassignments to a constant, but shows only O(1) maximum share. Byers et al. (Byers, 2003) proposed the use of the “power of two choices” algorithm. In this algorithm, each object is hashed to d ≥ 2 different IDs, and is placed in the least loaded node of the nodes
167
Load Balancing in Peer-to-Peer Systems
responsible for those IDs. The other nodes are given a redirection pointer to the destination node so that searching is not slowed significantly. For homogeneous nodes and objects and a static system, picking d = 2 achieves a load balance within a (log log n) factor of optimal, and when d = Θ(log n), the load balance is within a constant factor of optimal. The ID assignment or reassignment methods reassign IDs to nodes in order to maintain the load balance when nodes arrive and depart the system. The object transfer and neighbor update involved in ID rearrangement would incur a high overhead. Moreover, few methods directly take into account the heterogeneity of file load.
3.1.3 Load Transfer The virtual server methods and key assignment and reassignment methods ignore the heterogeneity of file load. Further load imbalance may result from non-uniform distribution of files in the identifier space and a high degree of heterogeneity in file loads and node capacities. In addition, few of the methods are able to deal with both the network churn and proximity. In general, the DHT churn should be dealt with by randomized matching between heavily loaded nodes with lightly loaded nodes. Load transfer methods to move load from heavily loaded nodes to lightly loaded nodes can deal with these problems. Rao et al. (2003) proposed three algorithms to rearrange load based on nodes’ different capacities: one-to-one, many-to-many, and one-to-many. Their basic idea is to move virtual servers, i.e. load, from heavily loaded nodes to lightly loaded nodes so that each node’s load does not exceed its capacity. Specifically, the method periodically collects the information of servers’ load status, which helps load rearrangement between heavily loaded nodes and lightly loaded nodes. The algorithms are different primarily in the amount of information used to decide load rearrangement. In the one-to-one algorithm, each lightly loaded server randomly probes nodes for a match with a heavily loaded one. In the manyto-many algorithm, each heavily loaded server sends its excess virtual nodes to a global pool, which executes load rearrangement periodically. The one-to-one scheme produces too many probes, while the many-to-many scheme increases overhead in load rearrangement. As a trade-off, the one-to-many algorithm works in a way that each heavily loaded server randomly chooses a directory which contains information about a number of lightly loaded servers, and moves its virtual servers to lightly loaded servers until it is not overloaded anymore. In a DHT overlay, a node’s load may vary greatly over time since the system can be expected to experience continuous insertions and deletions of objects, skewed object arrival patterns, and continuous arrival and departure of nodes. To cope with this problem, Godfrey et al. (2006) extended Rao’s work (Rao, 2003) for dynamic DHT networks with rapid arrivals and departures of items and nodes. In their approach, if a node’s capacity utilization exceeds a predetermined threshold, its excess virtual servers will be moved to a lightly loaded node immediately without waiting for the next periodic balancing. This work studied this algorithm by using extensive simulations over a wide set of system scenarios and algorithm parameters. Most recently, Karger and Ruhl (2004) proved that the virtual server method could not be guaranteed to handle item distributions where a key ID interval has more than a certain fraction of the load. As a remedy, they proposed two schemes with provable features: moving items and moving nodes to achieve equal load between a pair of nodes, and then achieves a system-wide load balance state. In the moving items scheme, every node occasionally contacts a random other node. If one of the two nodes has much larger load than the other, then items are moved from the heavily loaded node to the lightly loaded node
168
Load Balancing in Peer-to-Peer Systems
until their loads become equal. In the moving nodes scheme, if a pair of nodes has very uneven loads, the load of the heavier node gets split between the two nodes by changing their addresses. However, this scheme breaks DHT mapping and cannot support key locations as usual. Karger and Ruhl (2004) provided a theoretic treatment for load balancing problem and proved that good load balance can be achieved by moving items if the fraction of address space covered by every node is O(1/n) (Karger, 2004). Almost all of these algorithms assume the objective of minimizing the amount of moved load. The algorithms treat all nodes equally in random probing, and neglect the factor of physical proximity on the effectiveness of load balancing. With proximity consideration, load transferring and communication should be within physically close heavy and light nodes. One of the first works to utilize the proximity information to guide load balancing is due to Zhu and Hu (2005). They presented a proximity-aware algorithm to take into account the node proximity information in load balancing. The authors suggested to build a K-nary tree (KT) structure on top of a DHT overlay. Each KT node is planted in a virtual server. A K-nary tree node reports the load information of its real server to its parent, until the tree root is reached. The root then disseminates final information to all the virtual nodes. Using this information, each real server can determine whether it is heavily loaded or not. Lightly loaded and heavily loaded nodes report their free capacity, excess virtual nodes information to their KT leaf nodes respectively. The leaf nodes will propagate the information upwards along the tree. When the total length of information reaches a certain threshold, the KT node would execute load rearrangement between heavily loaded nodes and lightly loaded nodes. The KT structure helps to use proximity information to move load between physically close heavily and lightly loaded nodes. However, the construction and maintenance of KT are costly, especially in churn. In churn, a KT will be destroyed without timely fixes, degrading load balancing efficiency. For example, when a parent fails or leaves, the load imbalance of its children in the subtree cannot be resolved before its recovery. Therefore, although the network is self-organized, the algorithm is hardly applicable to DHTs with churn. Besides, the tree needs to be reconstructed every time after virtual server transferring, which is imperative in load balancing. Second, a real server cannot start determining its load condition until the tree root gets the accumulated information from all nodes. This centralized process is inefficient and hinder the scalability improvement of P2P systems.
3.2 Case Study: Locality-Aware Randomized Load Balancing Algorithms This section presents Locality-Aware Randomized load balancing algorithms (LAR) (Shen, 2007) that take into account proximity information in load balancing and deal with network dynamism meanwhile. The algorithms take advantage of the proximity information of the DHTs in node probing and distribute application load among the nodes according to their capacities. The LAR algorithms introduce a factor of randomness in the probing of lightly loaded nodes in a range of proximity so as to make the probing process robust in DHTs with churn. The LAR algorithms further improve the efficiency by allowing the probing of multiple candidates at a time. Such a probing process is referred as d-way probing, d ≥ 1. The algorithms are implemented in Cycloid (Shen, 2006), based on a concept of “moving item” (Karger, 2004) for retaining DHT network efficiency and scalability. The algorithms are also suitable for virtual server methods. The performance of the LAR load balancing algorithms is evaluated via comprehensive simulations. Simulation results demonstrate the superiority of a locality-aware 2-way randomized load balancing algorithm, in comparison with other pure random approaches and locality-aware sequential algorithms. In DHTs with churn, it performs no worse than the best churn resilient algorithm. In the
169
Load Balancing in Peer-to-Peer Systems
Table 1. Routing table of a cycloid node (4,101-1-1010) NodeID (4,101-1-1010) Routing Table Cubical neighbor: (3,101-0-xxxx) Cyclic neighbor: (3,101-1-1100) Cyclic neighbor: (3,101-1-0011) Leaf Sets (half smaller, half larger) Inside Leaf Set (3,101-1-1010)
(6,101-1-1010) Outside Leaf Set
(7,101-1-1001)
(6,101-1-1011)
following, Cycloid DHT is first introduced before the LAR algorithms are presented.
3.2.1 Cycloid: A Constant-Degree DHT Cycloid (Shen, 2006) is a lookup efficient constant-degree DHT that we recently proposed. In a Cycloid system with n = d ∙ 2d nodes, each lookup takes O(d) hops with O(1) neighbors per node. In this section, we give a brief overview of the Cycloid architecture and its self-organization mechanism, focusing on the structural features related to load balancing. ID and structure. In Cycloid, each node is represented by a pair of indices (k, ad−1 ad−2 . . . a0), where k is a cyclic index and ad−1 ad−2 . . . a0 is a cubical index. The cyclic index is an integer, ranging from 0 to d − 1 and the cubical index is a binary number between 0 and 2d − 1. Each node keeps a routing table and two leaf sets, inside leaf set and outside leaf set, with a total of 7 entries to maintain its connectivity to the rest of the system. Table 1 shows a routing state table for node (4,10111010) in an 8-dimensional Cycloid, where x indicates an arbitrary binary value. Its corresponding links in both cubical and cyclic Figure 1. Cycloid node routing links state
170
Load Balancing in Peer-to-Peer Systems
aspects are shown in Figure 1. In general, a node (k, ad−1 ad−2 . . . a0), k 6= 0, has one cubical neighbor (k − 1, ad−1a d−2 . . . ak xx...x) where x denotes an arbitrary bit value, and two cyclic neighbors (k−1, bd−1 bd−2 . . . b0) and (k−1, cd−1 cd−2 . . . c0). The cyclic neighbors are the first larger and smaller nodes with cyclic index k−1 mod d and their most significant different bit with the current node in cubical indices is no larger than (k − 1). That is, (k-1, bd−1 . . . b1b0) = min{∀(k-1, yd−1 . . . y1y0)|yd−1 . . . y0≥ad−1 . . . a1a0}, (k-1, cd−1 . . . c1c0) = max{∀(k-1, yd−1 . . . y1y0)|yd−1 . . . y0≤ad−1 . . . a1a0}. The node with a cyclic index k = 0 has no cubical neighbor or cyclic neighbors. The node with cubical index 0 has no small cyclic neighbor, and the node with cubical index 2d − 1 has no large cyclic neighbor. The nodes with the same cubical index are ordered by their cyclic index (mod d) on a local circle. The inside leaf set of a node points to the node’s predecessor and successor in the local circle. The largest cyclic index node in a local circle is called the primary node of the circle. All local circles together form a global circle, ordered by their cubical index (mod 2d). The outside leaf set of a node points to the primary nodes in its preceding and succeeding small circles in the global circle. The Cycloid connection pattern is resilient in the sense that even if many nodes are absent, the remaining nodes are still capable of being connected. The Cycloid DHT assigns keys onto its ID space by the use of a consistent hashing function. For a given key, the cyclic index of its mapped node is set to its hash value modulated by d and the cubical index is set to the hash value divided by d. If the target node of an item key (k, ad−1 . . . a1a0) is not present in the system, the key is assigned to the node whose ID is first numerically closest to ad−1 ad−2 . . . a0 and then numerically closest to k. Self-organization. P2P systems are dynamic in the sense that nodes are frequently joining and departing from the network. Cycloid deals with the dynamism in a distributed manner. When a new node joins, it initializes its routing table and leaf sets, and notifies the nodes in its inside leaf set of its participation. It also needs to notify the nodes in its outside leaf set if it becomes the primary node of its local circle. Before a node leaves, it notifies its inside leaf set nodes, as well. Because a Cycloid node has no incoming connections for cubical and cyclic neighbors, a leaving node cannot notify those who take it as their cubical neighbor or cyclic neighbor. The need to notify the nodes in its outside leaf set depends on whether the leaving node is a primary node or not. Updating cubical and cyclic neighbors are the responsibility of system stabilization, as in Chord.
3.2.2 Load Balancing Framework This section presents a framework for load balancing based on item movement on Cycloid. It takes advantage of the Cycloid’s topological properties and conducts a load balancing operation in two steps: local load balancing within a local circle and global load balancing between circles. A general approach with consideration of node heterogeneity is to partition the nodes into a super node with high capacity and a class of regular nodes with low capacity (Fasttrack, 2001; Yang, 2003). Each super node, together with a group of regular nodes, forms a cluster in which the super node operates as a server to the others. All the super nodes operate as equals in a network of super-peers. Super-peer networks strike a balance between the inherent efficiency of centralization and distribution, and take advantage of capacity heterogeneity, as well. Recall that each local circle in Cycloid has a primary node. We regard Cycloid as a quasi-super-peer network by assigning each primary node as a leading super node in its circle. A node
171
Load Balancing in Peer-to-Peer Systems
Table 2. Donating and starving sorted lists Load information in a primary node Donating sorted list
Starving sorted list
< δ Lj, Aj >
< Li,1, Di,1, Ai >
…
…
< δ Lm, Am >
< Li,k, Di,k, Ai >
is designated as supernode if its capacity is higher than a pre-defined threshold. The Cycloid rules are modified for node join and leave slightly to ensure that every primary node meets the capacity requirement of supernodes. If the cyclic ID selected by a regular node is the largest in its local circle, it needs to have another choose unless it is the bootstrap node of the circle. In the case of primary node departure or failure, a supernode needs to be searched in the primary node’s place if the node with the second largest cyclic ID in the circle is not a super node. This operation can be regarded as the new supernode leaves and re-joins the system with the ID of the leaving or failing primary node. Let Li,k denote the load of item k in node i. It is determined by the item size Si,k and the number of visits of the item Vi,k during a certain time period. That is, Li,k = Si,k ×Vi,k. The actual load of a real server i, denoted by Li, is the total load of all of its items: mi
Li = å Li,k , k =1
assuming the node has mi items. Let Ci denote the capacity of node i; it is defined as a pre-set target load which the node is willing to hold. We refer to the node whose actual load is no larger than its target load (i.e. Li ≤ Ci) as a light node; otherwise a heavy one. We define utilization of a node i, denoted by NUi, as the fraction of its target capacity that is occupied. That is, NUi= Li/Ci. System utilization, denoted by SU, is the ratio of the total actual load to the total node capacity. Each node contains a list of data items, labeled as Dk, k = 1, 2, .... To make full use of node capacity, the excess items chosen to transfer should be with minimum load. We define excess items of a heavy node as a subset of the resident items, satisfying the following condition. Without loss of generality, we assume the excess items are {D1,D2, . . ., Dm’}, 1≤ m’ ≤m. Their corresponding loads are {Li,1, ...,Li, m’}. The set of excess items is determined in such a way that m'
minimizes å Li,k
(1)
k =1
m'
subject to(L i - å Li,k ) £ C i
(2)
k =1
Each primary node has a pair of sorted donating and starving lists which store the load information of all nodes in its local cycle. A donating sorted list (DSL) is used to store load information of light nodes and a starving sorted list (SSL) is used to store load information of heavy nodes as shown in Table 2. The free capacity of light node i is defined as δLi = Ci − Li. Load information of heavy node I includes
172
Load Balancing in Peer-to-Peer Systems
the information of its excess items in a set of 3-tuple representation: < Li,1, Di,1, Ai >,< Li,k, Di,k, Ai >, . . ., , in which Ai denotes the IP address of node i. Load information of light node j is represented in the form of < δLj, Aj >. An SSL is sorted in a descending order of Li,k; minLi,k represents the item with the minimum load in the primary node’s starving list. A DSL is sorted in an ascending order of δLj ; max δLj represents the maximum δLj in the primary node’s donating list. Load rearrangement is executed between a pair of DSL and SSL, as shown in Algorithm 1. This scheme guarantees that heavier items have a higher priority to be reassigned to a light node, which means faster convergence to a system-wide load balance state. A heavy item Li,k is assigned to the mostfit light node with δLj which has minimum free capacity left after the heavy item Li,k is transferred to it. It makes full use of the available capacity. Our load balancing framework is based on item movement, which transfers items directly instead of virtual servers to save cost. Cycloid maintains two pointers for each transferred item. When an item D is transferred from heavy node i to light node j, node i will have a forward pointer in D location pointing to the item D in j’s place; item D will have a backward pointer to node i indicating its original host. When queries for item D reach node i, they will be redirected to node j with the help of forward pointer. If item D needs to be transferred from node j to another node, say g, for load balancing, node j will notify node i via its backward pointer of the item’s new location. Algorithm 1: Primary node periodically performs load rearrangement between a pair of DSL and SSL for each item k in SSL dofor each item j in DSL doifLi,k ≤ δ Ljthen Item k is arranged to be transferred from i to j ifδ Lj - Li,k > 0 then Put <(δ Li – Li,k),Ai> back to DSL We use a centralized method in local load balancing, and a decentralized method in global load balancing. Each node (k, ad−1a d−2 . . . a0) periodically reports its load information to the primary node in its local circle. Unlike a real super-peer network, Cycloid has no direct link between a node and the primary node. The load information needs to be forwarded using Cycloid routing algorithm, which ensures the information reaches the up-to-the-minute primary node. Specifically, the information is targeted to the node (d − 1, ad−1a d−2 . . . a0). By the routing algorithm, the destination it reaches, say node i, may be the primary node or its successor depending on which one is closer to the ID. If the cyclic index of the successor(i) is larger than the cyclic index of i, then the load information is forwarded to the predecessor(i), which is the primary node. Otherwise, node i is the primary node. According to the Cycloid routing algorithm, each report needs to take d/2 steps in the worst case. Cycloid cycle contains a primary node all the time. Since the load information is guaranteed to reach the up-to-the-minute primary node, there is no serious advert effect of primary node updates on load balancing. After receiving the load information, the primary node puts it to its own DSL and SSL accordingly. A primary node with nonempty starving list (PNS) first performs local load rearrangement between its DSL and SSL. Afterwards, if its SSL is still not empty, it probes other primary nodes’ DSLs for global load rearrangement one by one until its SSL becomes empty. When a primary node does’t have enough capacity for load balancing, it can search for a high capacity node to replace itself. We arrange the PNS to initiate probing because the probing process will stop once it is not overloaded. If a node of nonempty donating list initiates probing, the probing process could proceed infinitely, incurring much more communication messages and bandwidth cost. Because primary nodes are super peers with high capacities, they are less likely to be
173
Load Balancing in Peer-to-Peer Systems
overloaded in the load balancing. This avoids the situation that heavy nodes will be overloaded if they perform probing, such as in the schemes in (Rao, 2003). This scheme can be extended to perform load rearrangement between one SSL and multiple DSLs for improvement.
3.2.3 Locality-Aware Randomized Load Balancing Algorithms The load balancing framework in the preceding section facilitates the development of load balancing algorithms with different characteristics. A key difference between the algorithms is, for a PNS, how to choose another primary node for a global load rearrangement between their SSL and DSL. It affects the efficiency and overhead to reach a system-wide load balance state. D-way randomized probing. A general approach to dealing with the churn of DHTs is randomized probing. In the policy, each PNS probes other primary nodes randomly for load rearrangement. A simple form is one-way probing, in which a PNS, say node i, probes other primary nodes one by one to execute load rearrangement SSLi and DSLj, where j is a probed node. We generalize the one-way randomized probing policy to a d-way probing, in which d primary nodes are probed at a time, and the primary node with the most total free capacity in its DSL is chosen for load rearrangement. A critical performance issue is the choice of an appropriate value d. The randomized probing in our load balancing framework is similar to load balancing problem in other contexts: competitive online load balancing and supermarket model. Competitive online load balancing is to assign each task to a server on-line with the objective of minimizing the maximum load on any server, given a set of servers and a sequence of task arrivals and departures. Azar et al. (1994) proved that in competitive online load balancing, allowing each task to have two server choices to choose a less loaded server instead of just one choice can exponentially minimize the maximum server load and result in a more balanced load distribution. Supermarket model is to allocate each randomly incoming task modeled as a customer with service requirements, to a processor (or server) with the objective of reducing the time each customer spends in the system. Mitzenmacher et al. (1997) proved that allowing a task two server choices and to be served at the server with less workload instead of just one choice leads to exponential improvements in the expected execution time of each task. But a poll size larger than two gains much less substantial extra improvement. The randomized probing between the lists of SSLs and DSLs is similar to the above competitive load balancing and supermarket models if we regard SSLs as tasks, and DSLs as servers. But the random probing in P2P systems has a general workload and server models. Servers are dynamically composed with new ones joining and existent ones leaving. Servers are heterogeneous with respect to their capacities. Tasks are of different sizes and arrive in different rates. In (Fu, 2008), we proved the random probing is equivalent to a generalized supermarket model and showed the following results. Theorem 5.1: Assume servers join in a Poisson distribution. For any fixed time interval [0,T], the length of the longest queue in the supermarket model with d = 1 is ln n/ ln ln n(1+O(1)) with high probability; the length of the longest queue in the model with d ≥ 2 is ln ln n/ ln d + O(1), where n is the number of servers. The theorem implies that 2-way probing could achieve a more balanced load distribution with faster speed even in churn, because 2-way probing has higher possibility to reach an active node than 1-way probing, but d-way probing, d > 2, may not result in much additional improvement. Locality-aware probing. One goal of load balancing is to effectively keep each node lightly loaded
174
Load Balancing in Peer-to-Peer Systems
Table 3. Simulation settings and algorithm parameters Environmental Parameter
Default Value
Object arrival location
Uniform over ID space
Number of nodes
4906
Node capacity
Bounded Pareto: shape 2 lower bound: 2500, upper bound: 2500 * 10
Number of items
20480
Existing item load
Bounded Pareto: shape 2 lower bound: mean item actual load / 2 upper bound: mean item actual load / 2 * 10
with minimum load balancing overhead. Proximity is one of the most important performance factors. Mismatch between logical proximity abstraction and physical proximity information in reality is a big obstacle for the deployment and performance optimization issues for P2P applications. Techniques to exploit topology information in overlay routing include geographic layout, proximity routing and proximity-neighbor selection (Castro, 2002). The proximity-neighbor selection and topologically-aware overlay construction techniques in (Xu, 2003; Castro, 2002; Waldvogel, 2002) are integrated into Cycloid to build a topology-aware Cycloid. As a result, the topology-aware connectivity of Cycloid ensures that a message reaches its destination with minimal overhead. Details of topology-aware Cycloid construction will be presented in Section 3.2.4. In a topology-aware Cycloid network, the cost for communication and load movement can be reduced if a primary node contacts other primary nodes in its routing table or primary nodes of its neighbors. In general, the primary nodes of a node’s neighbors are closer to the node than randomly chosen primary nodes in the entire network, such that load is moved between closer nodes. This method should be the first work that handles the load balancing issue with the information used for achieving efficient routing. There are two methods for locality-aware probing: randomized and sequential method. 1.
2.
Locality-aware randomized probing (LAR): In LAR, each PNS contacts primary nodes in a random order in its routing table or primary nodes of its neighbors except the nodes in its inside leaf set. After all these primary nodes have been tried, if the PNS’s SSL is still nonempty, global random probing is started in the entire ID space. Locality-aware sequential probing (Lseq): In Lseq, each PNS contacts its larger outside leaf set Successor(PNS). After load rearrangement, if its SSL is still nonempty, the larger outside leaf set of Successor(PNS), Successor(Successor(PNS)) is tried. This process is repeated, until that SSL becomes empty. The distances between a node and its sequential nodes are usually smaller than distances between the node and randomly chosen nodes in the entire ID space.
3.2.4 Performance Evaluation We designed and implemented a simulator in Java for evaluation of the load balancing algorithms on topology-aware Cycloid. Table 3 lists the parameters of the simulation and their default values. The simulation model and parameter settings are not necessarily representative of real DHT applications. They are set in a similar way to related studies in literature for fair comparison. We will compare the
175
Load Balancing in Peer-to-Peer Systems
different load balancing algorithms in Cycloid without churn in terms of the following performance metrics; the algorithms in Cycloid with churn will also be evaluated. 1. 2.
3. 4.
5.
Load movement factor: Defined as the total load transferred due to load balancing divided by the system actual load, which is system target capacity times SU. It represents load movement cost. Total time of probing: Defined as the time spent for primary node probing assuming that probing one node takes 1 time unit, and probing a number of nodes simultaneously also takes 1 time unit. It represents the speed of probing phrase in load balancing to achieve a system-wide load balance state. Total number of load rearrangements: Defined as the total number of load rearrangement between a pair of SSL and DSL. It represents the efficiency of probing for light nodes. Total probing bandwidth: Defined as the sum of the bandwidth consumed by all probing operations. The bandwidth of a probing operation is the sum of bandwidth of all involved communications, each of which is the product of the message size and physical path length of the message traveled. It is assumed that the size of a message asking and replying for information is 1 unit. It represents the traffic burden caused by probings. Moved load distribution: Defined as the cumulative distribution function (CDF) of the percentage of moved load versus moving distance. It represents the load movement cost for load balance. The more load moved along the shorter distances, the less load balancing costs.
Topology-aware cycloid construction. GT-ITM (transit-stub and tiers) (Zegura, 1996) is a network topology generator, widely used for the construction of topology-aware overlay networks (Ratnasamy, 2002; Xu, 2003; Xu, 2003; Gummadi, 2003). We used GT-ITM to generate transit-stub topologies for Cycloid, and get physical hop distance for each pair of Cycloid nodes. Recall that we use proximityneighbor selection method to build topology-aware Cycloid; that is, it selects the routing table entries pointing to the physically nearest among all nodes with nodeID in the desired portion of the ID space. We use landmark clustering and Hilbert number (Xu, 2003) to cluster Cycloid nodes. Landmark clustering is based on the intuition that close nodes are likely to have similar distances to a few landmark nodes. Hilbert number can convert d dimensional landmark vector of each node to one dimensional index while still preserve the closeness of nodes. We selected 15 nodes as landmark nodes to generate the landmark vector and a Hilbert number for each node cubic ID. Because the nodes in a stub domain have close (or even same) Hilbert numbers, their cubic IDs are also close to each other. As a result, physically close nodes are close to each other in the DHT’s ID space, and nodes in one cycle are physically close to each other. For example, assume nodes i and j are very close to each other in physical locations but far away from node m. Nodes i and j will get approximately equivalent landmark vectors, which are different from m’s. As a result, nodes i and j would get the same cubical IDs and be assigned to the circle different from m’s. In the landmark approach, for each topology, we choose landmarks at random with the only condition that the landmarks are separated from each other by four hops. More sophisticated placement schemes, as described in (Jamin, 2000) would only serve to improve our results. Our experiments are built on two transit-stub topologies: “ts5k-large” and “ts5k-small” with approximately 5,000 nodes each. In the topologies, nodes are organized into logical domains. We classify the domains into two types: transit domains and stub domains. Nodes in a stub domain are typically an endpoint in a network flow; nodes in transit domains are typically intermediate in a network flow. “ts5klarge” has 5 transit domains, 3 transit nodes per transit domain, 5 stub domains attached to each transit
176
Load Balancing in Peer-to-Peer Systems
Figure 2. Effect of load balancing
node, and 60 nodes in each stub domain on average. “ts5k-small” has 120 transit domains, 5 transit nodes per transit domain, 4 stub domains attached to each transit node, and 2 nodes in each stub domain on average. “ts5k-large” has a larger backbone and sparser edge network (stub) than “ts5k-small”. “ts5klarge” is used to represent a situation in which Cycloid overlay consists of nodes from several big stub domains, while “ts5k-small” represents a situation in which Cycloid overlay consists of nodes scattered in the entire Internet and only few nodes from the same edge network join the overlay. To account for the fact that interdomain routes have higher latency, each interdomain hop counts as 3 hops of units of latency while each intradomain hop counts as 1 hop of unit of latency. Effectiveness of LAR algorithms. In this section, we will show the effectiveness of LAR load balancing algorithm. First, we present the impact of LAR algorithm on the alignment of the skews in load distribuFigure 3. Effect of load balancing due to different probing algorithms
177
Load Balancing in Peer-to-Peer Systems
tion and node capacity when the system is fully loaded. Figure 2(a) shows the initial node utilization of each node. Recall that node utilization is a ratio of the actual load to its target (desired) load. Many of the nodes were overloaded before load balancing. Load balancing operations drove all node utilizations down below 1 by transferring excess items between the nodes, as shown in Figure 2(b). Figure 2(c) shows the scatterplot of loads according to node capacity. It confirms that the capacity-aware load balancing feature of the LAR algorithm. Recall that LAR algorithm was based on item movement, using forward pointers to keep DHT lookup protocol. We calculated the fraction of items that are pointed to by forward pointers in systems of different utilization levels. We found that the fraction increased linearly with the system load, but it would be no higher than 45% even when the system becomes fully loaded. The cost is reasonably low compared to the extra space, maintenance cost and efficiency degradation in virtual server load balancing approach. We measured the load movement factors due to different load balancing algorithms: one-way random (R1), two-way random (R2), LAR1, LAR2, and Lseq, on systems of different loads and found that the algorithms led to almost the same amount of load movement in total at any given utilization level. This is consistent with the observations by Rao et al. (2003) that the load moved depends only on distribution of loads, the target to be achieved, but not on load balancing algorithms. This result suggests that an effective load balancing algorithm should explore to move the same amount of load along shorter distance and in shorter time to reduce load balancing overhead. In the following, we will examine the performance of various load balancing algorithms in terms of other performance metrics. Because metrics (2) and (3) are not affected by topology, the results of them in “ts5k-small” will not be presented sometimes. Comparison with other algorithms.Figure 3(a) shows the probing process in Lseq takes much more time than R1 and LAR1. This implies that random algorithm is better than sequential algorithm in probing efficiency. Figure 3(b) shows that the numbers of rearrangements of the three algorithms are almost the same. This implies that they need almost the same number of load rearrangement to achieve load balance. However, long probing time of Lseq suggests that it is not as efficient as random probing. It is consistent with the observation of Mitzenmacher in (Mitzenmacher, 1997) that simple randomized load balancing schemes can balance load effectively. Figure 3(c) and (d) show the performance of the algorithms in “ts5k-large”. From Figure 3(c), we can observe that unlike in lightly loaded systems, in heavily loaded systems, R1 takes more bandwidth than LAR1 and Lseq, and the performance gap increases as the system load increases. This is because that much less probings are needed in a lightly loaded system, causing less effect of probing distance on bandwidth consumption. The bandwidth results of LAR and Lseq are almost the same when the SU is under 90%; when the SU goes beyond 0.9, LAR consumes more bandwidth than Lseq. This is due to the fact that in a more heavily loaded system, more nodes need to be probed in the entire ID space, leading to longer load transfer distances. Figure 3(d) shows the moved load distribution in load balancing as the SU approaches 1. We can see that LAR1 and Lseq are able to transfer about 60% of global moved load within 10 hops, while R1 transfers only about 15% because R1 is locality-oblivious. Figure 3(e) and (f) show the performance of the algorithms in “ts5k-small”. These results also confirm that LAR1 achieve better locality-aware performance than R1, although the improvement is not so significant as in “ts5k-large”. It is because that in “ts5k-small” topology,nodes are scattered in the entire network, and the neighbors of a primary node may not be physically closer than other nodes.
178
Load Balancing in Peer-to-Peer Systems
Figure 4. Breakdown of probed nodes
Figures 3(d) and (f) also include the results due to two other popular load balancing approaches: proximity-aware Knary Tree (KTree) algorithm (Zhu, 2005) and churn resilient algorithm (CRA) (Godfrey, 2006) for comparison. From the figures, we can see that LAR performs as well as KTree, and outperforms proximity-oblivious CRA, especially in “ts5k-large”. The performance gap between proximity-aware and proximity-oblivious algorithms is not as large as in “ts5k-small”. It is because the nodes in “ts5k-small” are scattered in the entire Internet with less locality.
Figure 5. Effect of load balancing due to different LAR algorithms
179
Load Balancing in Peer-to-Peer Systems
In summary, the results in Figure 3 suggest that the randomized algorithm is more efficient than the sequential algorithm in the probing process. The locality-aware approaches can effectively assign and transfer loads between neighboring nodes first, thereby reduce network traffic and improve load balancing efficiency. The LAR algorithm performs no worse than the proximity-aware KTree algorithm. In Section 3.2.5, we will show LAR works much better for DHTs with churn. Effect of D-way random probing (Figure 4). We tested the performance of the LARd algorithms with different probing concurrency degree d. Figure 5(a) shows that LAR2 takes much less probing time than LAR1. It implies that LAR2 reduces the probing time of LAR1 at the cost of more number of probings. Unlike LAR1, in LAR2, a probing node only sends its SSL to a node with more total free capacity in its DSL between two probed nodes. The more item transfers in one load rearrangement, the less probing time. It leads to less number of SSL sending operation of LAR2 than LAR1, resulting in less number of load rearrangements as shown in Figure 5(b). Therefore, simultaneous probings to get a node with more total free capacity in its DSL can save load balancing time and reduce network traffic load. Figures 4(a) and (b) show the breakdown of total number of probed nodes in percentage that are from neighbors or randomly chosen in entire ID space in LAR1 and LAR2 respectively. Label “one neighbor and one random” represents the condition when there’s only one neighbor in routing table, then another probed node is chosen randomly from ID space. We can see that the percentage of neighbor primary node constitutes the most part, which means that neighbors can support most of system excess items in load balancing. With SU increases, the percentage of neighbor primary node decreases because the neighbors’ DSLs don’t have enough free capacity for a larger number of excess items, then randomly chosen primary nodes must be resorted to. Figures 5(a) and (b) show that the probing efficiency of LARd (d>2) is almost the same as LAR2, though they need to probe more nodes than LAR2. The results are consistent with the expectations in Section 3.2.1 that a two-way probing method leads to an exponential improvement over one-way probing, but a d-way (d>2) probing leads to much less substantial additional improvement. In the following, we will analyze whether the improvement of LARd (d ≥ 2) over LAR1 is at the cost of more bandwidth consumption or locality-aware performance degradation. We can observe from Figure 5(c) that the probing bandwidth of LAR2 is almost the same as LAR1. Figure 5(d) shows the moved load distribution in global load balancing due to different algorithms. We can see that LAR2 leads to an approximately identical distribution as LAR1 and they cause slightly less global load movement cost than LAR4 and LAR6. This is because the more simultaneous probed nodes, the less possibility that the best primary node is a close neighbor node. These observations demonstrate that LAR2 improves on LAR1 at no cost of bandwidth consumption. It retains the advantage of locality-aware probing. Figures 5(e) and (f) show the performance of different algorithms in “ts5k-small”. Although the performance gap is not as wide as in ‘ts5k-large”, the relative performance between the algorithms retains. In practice, nodes and items continuously join and leave P2P systems. It is hard to achieve the objective of load balance in networks with churn. We conducted a comprehensive evaluation of the LAR algorithm in dynamic situations and compare the algorithm with CRA, which was designed for DHTs with churn. The performance factors we considered include load balancing frequency, item arrival/departure rate, non-uniform item arrival pattern, and network scale and node capacity heterogeneity. We adopted the same metrics as in (Godfrey, 2006):
180
Load Balancing in Peer-to-Peer Systems
Figure 6. Effect of load balancing with churn
1.
2.
The 99.9th percentile node utilization (99.9th NU). We measure the maximum 99.9th percentile of the node utilizations after each load balancing period T in simulation and take the average of these results over a period as the 99.9th NU. The 99.9th NU represents the efficiency of LAR to minimize load imbalance. Load moved/DHT load moved (L/DHT-L), defined as the total load moved incurred due to load balancing divided by the total load of items moved due to node joins and departures in the system. This metric represents the efficiency of LAR to minimize the amount of load moved.
Unless otherwise indicated, we run each trial of the simulation for 20T simulated seconds, where T is a parameterized load balancing period, and its default value was set to 60 seconds in our test. The item and node join/departure rates were modeled by Poisson processes. The default rate of item join/ departure rate was 0.4; that is, there were one item join and one item departure every 2.5 seconds. We ranged node interarrival time from 10 to 90 seconds, with 10 second increment in each step. A node life time is computed by arrival rate times number of nodes in the system. The default system utilization SU was set to 0.8. Performance comparison with CRA in Churn.Figure 6 plots the performance due to LAR1 and CRA versus node interarrival time during T period. By comparing results of LAR1 and CRA, we can have a number of observations. First, the 99.9th NUs of LAR1 and CRA are kept no more than 1 and 1.25 reFigure 7. Impact of system utilization under continual node joins and departures
181
Load Balancing in Peer-to-Peer Systems
Figure 8. Impact of load balancing frequency
spectively. This implies that on average, LAR1 is comparable with CRA in achieving the load balancing goal in churn. Second, LAR1 moves up to 20% and CRA moves up to 45% of the system load to achieve load balance for SU as high as 80%. Third, the load moved due to load balancing is very small compared with the load moved due to node joins and departures and it is up to 40% for LAR1 and 53% for CRA. When the node interarrival time is 10, the L/DHT-L is the highest. It is because faster node joins and departures generate much higher load imbalance, such that more load transferred is needed to achieve load balance. The fact that the results of LAR1 are comparable to CRA implies that LAR algorithm is as efficient as CRA to handle churn by moving a small amount load. The results in Figure 6 are due to a default node join/leave rate of 0.4. Figure 7 plots the 99.9th NU, load movement factor and the L/DHT-L as a function of SU with different node interarrival time respectively. We can observe that the results of the three metrics increase as SU increases. That’s because nodes are prone to being overloaded in a heavily loaded system, resulting in more load transferred to achieve load balance. We also can observe that the results of the metrics increase as interarrival time decreases, though they are not obvious. It is due to the fact that with faster node joins and departures, nodes are more easily to become overloaded, leading to the increase of the 99.9th NU and load moved in load balancing. Low NUs in different SU and node interarrival time means that the LAR is effective in maintaining each node light in a dynamic DHT with different node join/departure rate and different SUs, and confirms the churn-resilient feature of the LAR algorithm. Impact of load balancing frequency in Churn. It is known that high frequent load balancing ensures the system load balance at a high cost, and low frequent load balancing can hardly guarantee load balance at all time. In this simulation, we varied load balancing interval T from 60 to 600 seconds, at a step size of 60, and we conducted the test in a system with SU varies from 0.5 to 0.9 at a step size of 0.1. Figure 8(a) and (b) show the 99.9th NU and load movement factor in different system utilization and time interval. We can see that the 99.9th NU and load movement factor increase as SU increases. This is because that nodes are most likely to be overloaded in highly loaded system, leading to high maximum NU and a large amount of load needed to transfer for load balance. Figure 8(a) shows that all the 99.9th NUs are less than 1, and when the actual load of a system consists
182
Load Balancing in Peer-to-Peer Systems
Figure 9. Impact of item arrival/departure rate
more than 60% of its target load, the 99.9 NU quickly converges to 1. It implies that the LAR algorithm is effective in keeping every node light, and it can quickly transfer excess load of heavy nodes to light nodes even in a highly loaded system. Observing Figure 8(a) and (b), we find that in a certain SU, the more load moved, the lower 99.9th NU. It is consistent with our expectation that more load moved leads to move balanced load distribution. Intuitively, a higher load balancing frequency should lead to less the 99.9th NU and more load moved. Our observation from Figure 8 is counter-intuitive. That is, the 99.9th NU increases and load movement factor decreases as load balancing is performed more frequently. Recall that the primary objective of load balancing is to keep each node not overloaded, instead of keeping the application load evenly distributed between the nodes. Whenever a node’s utilization is below 1, it does not need to transfer its load to others. With a high load balancing frequency, few nodes are likely to be overloaded. They may have high utilizations less than 1, and end up with less load movement and high node utilization. Figure 8(b) reveals a linear relationship between the load movement factor and system utilization and that the slope of low frequency is larger than high frequency because of the impact of load balancing frequency on highly loaded systems. Impact of item arrival/departure rate in Churn. Continuous and fast item arrivals increase the probability of overloaded nodes generation. Item departures generate nodes with available capacity for excess items. An efficient load balancing algorithm will find nodes with sufficient free capacity for excess items quickly in order to keep load balance state in churn. In this section, we evaluate the efficiency of LAR algorithm in the face of rapid item arrivals and departures. In this test, we varied item arrival/departure rate from 0.05 to 0.45 at a step size of 0.1, varied SU from 0.5 to 0.9 at a step size of 0.05, and measured the 99.9th NU and load movement factor in each condition. Figure 9(a) and (b), respectively, plot the 99.9th NU and load movement factor as functions of item arrival/departure rate. As expected, the 99.9th NU and load movement factor increase with system utilization. It is consistent with the results in the load balancing frequency test. Figure 9(a) shows that all the 99.9th NUs are less than 1, which means that the LAR is effective to assign excess items to light nodes in load balancing in rapid item arrivals and departures. From the figures, we can also see that when item arrival/departure
183
Load Balancing in Peer-to-Peer Systems
Figure 10. Impact of non-uniform item arrival patterns
rate increases, unlike in lightly loaded system, the 99.9th NU decreases in heavily loaded system. It is due to efficient LAR load balancing, in which more load rearrangements initiated timely by overloaded nodes with high item arrival rate. On the other hand, in the lightly loaded system, though the loads of nodes accumulate quickly with high item arrival rate, most nodes are still light with no need to move out load, leading to the increase of 99.9th NU. This is confirmed by the observation in Figure 9(b) that the load moved is higher in heavily loaded system than that in lightly loaded system, and movement factor drops faster in highly loaded system, which means that faster item departures lead to less load moved for load balance. Figure 9(b) demonstrates that the load movement factor drops as item arrival/ departure rate increases. It is because that the total system load (denominator of load movement factor) grows quickly with a high item arrival/departure rate. In summary, item arrival/departure rate has direct effect on NU and load movement factor in load balancing, and LAR is effective to achieve load balance with rapid item arrivals and departures. Impact of Non-uniform Item Arrivals in Churn. Furthermore, we tested LAR algorithm to see if it is churn-resilient enough to handle skewed load distribution. We define an “impulse” of items as a group of items that suddenly join in the system and their IDs are distributed over a contiguous interval of an ID space interval. We set their total load as 10% of the total system load, and varied the spread of interval from10% to 90% of the ID space. Figure 10(a) shows that in different impulses and SUs, LAR algorithm kept the 99.9th NU less than 1.055, which implies that LAR algorithm can almost solve the impulses successfully. The 99.9th NU is high in high SU and low impulse spread. Except when SU equals to 0.8, the impulse with spread larger than 0.3 can be successfully resolved by LAR algorithm. When the impulse is assigned to a small ID space interval less than 0.3, the load of the nodes in that ID space interval accumulates quickly, leading to higher NUs. The situation becomes worse with higher SU, because there’s already less available capacity left in the system for the impulse. The curve of SU=0.8 is largely above others is mainly due to the item load and node capacity distributions, and the impulse load relative to the SU. In that case, it is hard to find nodes with large enough capacity to support excess items because of the fragmentation of the 20% capacity left in the system. The results are consistent with the results in paper (Godfrey, 2006). Figure 10(b) shows that the load movement factor decreases with the increase of impulse spread, and the decrease of SU. In low impulse spread, a large amount of load assigning to a small region generates
184
Load Balancing in Peer-to-Peer Systems
Figure 11. Impact of the number of nodes in the system
a large number of overloaded nodes, so the LAR load balancing algorithm cannot handle them quickly. This situation becomes worse when SU increases to 0.8, due to little available capacity left. Therefore, the 99.9th NU and the load movement factor are high in highly loaded system and low impulse interval. In summary, the LAR algorithm can solve non-uniform item arrival generally. It can deal with sudden increase of 10% load in 10% ID space in a highly loaded system with SU equals to 0.8, achieving the 99.9th NU close to 1. Impact of Node Number and Capacity Heterogeneity in Churn. Consistent hashing function adopted in DHT leads to a bound of O(log n) imbalance of keys between the nodes, where n is the number of nodes in the system. Node heterogeneity in capacity makes the load balancing problem even more severe. In this section, we study the effects of the number of nodes and heterogeneous capacity distribution in the system on load balancing. We varied the number of nodes from 1000 to 8000 at a step size of 1000, and tested NU and load movement factor when node capacities were heterogeneous and homogeneous. Homogeneous node capacities are equal capacities set as 50000, and heterogeneous node capacities are determined by the default Pareto node capacity distribution. Figure 11(a) shows that in the heterogeneous case, the 99.9th NUs are all around 1. It means that the LAR can maintain nodes to be light in different network scales when node capacities are heterogeneous. In the homogeneous case, the 99.9th NU maintains around 1 when node number is no more than 5000, but it grows linearly as node number increases when nodes are more than 5000. It is somewhat surprisingly that LAR can achieve better load balance in large scale network when node capacities are heterogeneous than when they are homogeneous. Intuitively, this is because that in the heterogeneous case, very high load items can be accommodated by large capacity nodes, but there’s no node with capacity large enough to handle them in the homogeneous case. The results are consistent with those in (Godfrey, 2006). Figure 11(b) shows that in both cases, the load movement factors increase as the number of nodes grows. Larger system scale generates higher key imbalance, such that more load needs to be transferred for load balance. The figure also shows that the factor of the homogeneous case is pronounced less than that in the heterogeneous case. This is due to the heterogeneous capacity distribution, in which some nodes have very small capacities but are assigned much higher load, which is needed to move out for load balance. The results show that node heterogeneity helps, not hurts, the scalability of LAR algorithm. LAR algorithm can achieve good load balance even in large scale network by arranging load transfer
185
Load Balancing in Peer-to-Peer Systems
timely.
3.2.6. Summary This section presents LAR load balancing algorithms to deal with both of the proximity and dynamism of DHTs simultaneously. The algorithms distribute application load among the nodes by “moving items” according to their capacities and proximity information in topology-aware DHTs. The LAR algorithms introduce a factor of randomness in the probing process in a range of proximity to deal with DHT churn. The efficiency of the randomized load balancing is further improved by d-way probing. Simulation results show the superiority of a locality-aware 2-way randomized load balancing in DHTs with and without churn. The algorithm saves bandwidth in comparison with randomized load balancing because of its locality-aware feature. Due to the randomness factor in node probing, it can achieve load balance for SU as high as 90% in dynamic situations by moving load up to 20% of the system load, and up to 40% of the underlying DHT load moved caused by node joins and departures. The LAR algorithm is further evaluated with respect to a number of performance factors including load balancing frequency, arrival/departure rate of items and nodes, skewed item ID distribution, and node number and capacity heterogeneity. Simulation results show that LAR algorithm can effectively achieve load balance by moving a small amount of load even in skewed distribution of items.
4. FUTURE TRENDS Though a lot of research has been conducted in the field of load balancing in parallel and distributed systems, load balancing methods are still in their incubation phase when it comes to P2P overlay networks. In this section, we discuss the future and emerging trends, and present a number of open issues in the domain of load balancing in P2P overlay networks. P2P overlay networks are characterized by heterogeneity, dynamism and proximity. With heterogeneity consideration, a load balancing method should allocate load among nodes based on the actual file load rather than the number of files. A dynamism-resilient load balancing method should not generate high overhead in load balancing when nodes join, leave or fail continuously and rapidly. A proximity-aware load balancing method moves load between physically close nodes so as to reduce the overhead of load balancing. However, few of the current load balancing methods take into account these three factors to improve the efficiency and effectiveness of load balancing. Virtual server methods and ID assignment and reassignment methods only aim to distribute the number of files among nodes in balance, therefore they are unable to consider file heterogeneity. In addition, these methods lead to high overhead due to neighbor maintenance and varied ID intervals owned by nodes in churn. These two categories of methods can be complementary to the load transfer methods that have potential to deal with the three features of P2P overlay networks. Thus, combing the three types of load balancing strategies to overcome each other’s drawbacks and take advantage of the benefits of each method will be a promising future direction. The LAR algorithms were built on Cycloid structured DHT. It is important that the LAR algorithms are applicable to other DHT networks as well. It must be complemented by node clustering to cluster DHT nodes together according to their physical locations to facilitate LAR’s probing in a range of proximity. The work in (Shen, 2006) presents a way of clustering physically close nodes in a general DHT network, which can be applied to LAR’s generalization to other DHT networks.
186
Load Balancing in Peer-to-Peer Systems
Currently, most heterogeneity-unaware load balancing methods measure load by the number of files stored in a node, and heterogeneity-aware load balancing methods only consider file size when determining a node’s load. In addition to the storage required, the load incurred by a file also includes bandwidth consumption caused by file queries. Frequently-queried files generate high load, while infrequentlyqueried files lead to low load. Since files stored in the system often have different popularities, and the access patterns to the same file may vary with time, a file’s load is changing dynamically. However, most load balancing methods are not able to cope with load variance caused by non-uniform and time-varying file popularity. Thus, an accurate method to measure a file’s load that considers all factors affecting load is required. On the other hand, node capacity heterogeneity should also be identified. As far as the author knows, all current load balancing methods assume that there is one bottleneck resource, though there are various resources including CPU, memory, storage and bandwidth. For highly effective load balancing, the various loads such as bandwidth and storage should be differentiated, and various node resources should be differentiated as well. Rather than mapping generalized node capacity and load, corresponding load and node resource should be mapped in load balancing. These improvements will significantly enhance the accuracy and effectiveness of a load balancing method. Most load balancing algorithms only balances key distribution among nodes. In file sharing P2P systems, a main function of nodes is to handle key location query. Query load balancing is a critical part of P2P load balancing. That is, the number of queries that nodes receive, handle and forward corresponds to their different capacities. A highly effective load balancing method will distribute both key load and query load in balance.
5. CONCLUSION A load balancing method is indispensable to a high performance P2P overlay network. It helps to avoid overloading nodes and take full advantage of node resources in the system. This chapter has provided a detailed introduction of load balancing in P2P overlay networks, and has examined all aspects of load balancing methods including their goals, properties, strategies and classification. A comprehensive review of research works focusing on load balancing in DHT networks has been presented, along with an in depth discussion of their pros and cons. Furthermore, a load balancing algorithm that overcomes the drawbacks of previous methods has been presented in detail. Finally, the future and emerging trends and open issues in load balancing in P2P overlay networks have been discussed.
REFERENCES Adler, M., Halperin, E., Karp, R. M., & Vazirani, V. (2003, June). A stochastic process on the hypercube with applications to peer-to-peer networks. In Proc. of STOC. Azar, Y. Broder, A., et al. (1994). Balanced allocations. In Proc. of STOC (pp. 593–602). Bienkowski, M., Korzeniowski, M., & auf der Heide, F. M. (2005). Dynamic load balancing in distributed hash tables. In Proc. of IPTPS.
187
Load Balancing in Peer-to-Peer Systems
Brighten Godfrey, P., & Stoica, I. (2005). Heterogeneity and load balance in distributed hash tables. In Proc. of IEEE INFOCOM. Byers, J. Considine, J., & Mitzenmacher, M. (2003, Feb.). Simple load balancing for distributed hash tables. In Proc. of IPTPS. Castro, M., Druschel, P., Hu, Y. C., & Rowstron, A. (2002). Topology-aware routing in structured peerto-peer overlay networks. In Future Directions in Distributed Computing. Fasttrack product description. (2001). http://www.fasttrack.nu/index.html. Fu, S., Xu, C. Z., & Shen, H. (April 2008). Random choices for Churn resilient load balancing in peerto-peer networks. Proc. of IEEE International Parallel and Distributed Processing Symposium. Godfrey, B., Lakshminarayanan, K., Surana, S., Karp, R., & Stoica, I. (2006). Load balancing in dynamic structured P2P systems. Performance Evaluation, 63(3). Gummadi, K., Gummadi, R., Gribble, S., Ratnasamy, S., Shenker, S., & Stoica, I. (2003). The impact of DHT routing geometry on resilience and proximity. In Proc. of ACM SIGCOMM. Jamin, S., Jin, C., Jin, Y., Raz, D., Shavitt, Y., & Zhang, L. (2000). On the placement of Internet instrumentation. In Proc. of INFOCOM. Kaashoek, F., & Karger, D. R. Koorde. (2003). A simple degree-optimal hash table. In Proceedings IPTPS. Karger, D., Lehman, E., Leighton, T., Levine, M., et al. (1997). Consistent hashing and random trees: Distributed caching protocols for relieving hot spots on the World Wide Web. In Proc. of STOC (pp 654–663). Karger, D. R., & Ruhl, M. (2004). Simple efficient load balancing algorithms for Peer-to-Peer systems. In Proc. of IPTPS. Manku, G. (2004). Balanced binary trees for ID management and load balance in distributed hash tables. In Proc. of PODC. Maymounkov, P., & Mazires, D. Kademlia. (2002). A peer-to-peer information system based on the xor metric. The 1st Interational Workshop on Peer-to-Peer Systems (IPTPS). Mitzenmacher, M. (1997). On the analysis of randomized load balancing schemes. In Proc. of SPAA. Mondal, A., Goda, K., & Kitsuregawa, M. (2003). Effective load-balancing of peer-to-peer systems. In Proc. of IEICE DEWS DBSJ Annual Conference. Motwani, R., & Raghavan, P. (1995). Randomized Algorithms. New York: Cambridge University Press. Naor, M., & Wieder, U. (June 2003). Novel Architectures for P2P applications: The continuous-discrete approach. In Proc. SPAA. Rao, A., Lakshminarayanan, K., et al. (2003). Load balancing in structured P2P systems. In Proc. of IPTPS.
188
Load Balancing in Peer-to-Peer Systems
Ratnasamy, S., Francis, P., Handley, M., Karp, R., & Shenker, S. (2001). A scalable content-addressable network. In Proceedings of ACM SIGCOMM. (pp 329–350). Ratnasamy, S., Handley, M., Karp, R., & Shenker, S. (2002). Topologically aware overlay construction and server selection. In Proc. of INFOCOM. Rowstron, A., & Druschel, P. Pastry. (2001). Scalable, decentralized object location and routing for large-scale peer-to-peer systems. In Proc. of the 18th IFIP/ACM Int’l Conf. on Distributed Systems Platforms (Middleware). Saroiu, S., et al. (2002). A Measurement Study of Peer-to- Peer File Sharing Systems. In Proc. of MMCN. Shen, H., & Xu, C. (2006,April). Hash-based proximity clustering for load balancing in heterogeneous DHT networks. In Proc. of IPDPS. Shen, H., Xu, C., & Chen, G. (2006). Cycloid: A scalable constant-degree P2P overlay network. Performance Evaluation, 63(3), 195–216. doi:10.1016/j.peva.2005.01.004 Shen, H., & Xu, C.-Z. (2007). Locality-aware and Churn-resilient load balancing algorithms in structured peer-to-peer networks. [TPDS]. IEEE Transactions on Parallel and Distributed Systems, 18(6), 849–862. doi:10.1109/TPDS.2007.1040 Stoica, I., Morris, R., et al. (2003). Chord: A scalable peer-to-peer lookup protocol for Internet applications. IEEE/ACM Transactions on Networking. Waldvogel, M., & Rinaldi, R. (2002). Efficient topology-aware overlay network. In Proc. of HotNets-I. Xu, C. (2005). Scalable and Secure Internet Services and Architecture. Boca Raton, FL: Chapman & Hall/CRC Press. Xu, Z., Mahalingam, M., & Karlsson, M. (2003). Turning heterogeneity into an advantage in overlay routing. In Proc. of INFOCOM. Xu, Z., Tang, C., & Zhang, Z. (2003). Building topology-aware overlays using global soft-state. In Proc. of ICDCS. Yang, B., & Garcia-Molina, H. (2003). Designing a super-peer network. In Proc. of ICDE. Zegura, E. Calvert, K. et al. (1996). How to model an Internetwork. In Proc. of INFOCOM. Zhao, B. Y., Kubiatowicz, J., & Oseph, A. D. (2001). Tapestry: An infrastructure for fault-tolerant wide-area location and routing (Tech. Rep. UCB/CSD-01-1141). University of California at Berkeley, Berkeley, CA. Zhu, Y., & Hu, Y. (2005). Efficient, proximity-aware load balancing for DHT-based P2P systems. Proc. of IEEE TPDS, 16(4).
189
Load Balancing in Peer-to-Peer Systems
KEY TERMS AND DEFINITIONS Dynamism/Churn: A great number of nodes join, leave and fail continually and rapidly, leading to unpredicted network size. Heterogeneity: The instinct properties of participating peers, including computing ability, differ a lot and deserve serious consideration for the construction of a real efficient wide-deployed application. Load Balancing Method: A method that controls the load in each node no more than the node’s capacity. Peer: A peer (or node) is an abstract notion of participating entities. It can be a computer process, a computer, an electronic device, or a group of them. Peer-to-Peer Network: A peer-to-peer network is a logical network on top of physical networks in which peers are organized without any centralized coordination. Proximity: Mismatch between logical proximity abstraction derived from DHTs and physical proximity information in reality, which is a big obstacle for the deployment and performance optimization issues for P2P applications. Structured Peer-to-Peer Network/Distributed Hash Table: A peer-to-peer network that maps keys to the nodes based on a consistent hashing function.
190
191
Chapter 9
Decentralized Overlay for Federation of Enterprise Clouds Rajiv Ranjan The University of Melbourne, Australia Rajkumar Buyya The University of Melbourne, Australia
ABSTRACT This chapter describes Aneka-Federation, a decentralized and distributed system that combines enterprise Clouds, overlay networking, and structured peer-to-peer techniques to create scalable wide-area networking of compute nodes for high-throughput computing. The Aneka-Federation integrates numerous small scale Aneka Enterprise Cloud services and nodes that are distributed over multiple control and enterprise domains as parts of a single coordinated resource leasing abstraction. The system is designed with the aim of making distributed enterprise Cloud resource integration and application programming flexible, efficient, and scalable. The system is engineered such that it: enables seamless integration of existing Aneka Enterprise Clouds as part of single wide-area resource leasing federation; self-organizes the system components based on a structured peer-to-peer routing methodology; and presents end-users with a distributed application composition environment that can support variety of programming and execution models. This chapter describes the design and implementation of a novel, extensible and decentralized peer-to-peer technique that helps to discover, connect and provision the services of Aneka Enterprise Clouds among the users who can use different programming models to compose their applications. Evaluations of the system with applications that are programmed using the Task and Thread execution models on top of an overlay of Aneka Enterprise Clouds have been described here.
INTRODUCTION Wide-area overlays of enterprise Grids (Luther, Buyya, Ranjan, & Venugopal, 2005; Andrade, Cirne, Brasileiro, & Roisenberg, 2003; Butt, Zhang, & Hu, 2003; Mason & Kelly, 2005) and Clouds (Amazon DOI: 10.4018/978-1-60566-661-7.ch009
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Decentralized Overlay for Federation of Enterprise Clouds
Elastic Compute Cloud, 2008; Google App Engine, 2008; Microsoft Live Mesh, 2008; Buyya, Yeo, Venugopal, 2008) are an appealing platform for the creation of high-throughput computing resource pools and cross-domain virtual organizations. An enterprise Cloud1 is a type of computing infrastructure that consists of a collection of inter-connected computing nodes, virtualized computers, and software services that are dynamically provisioned among the competing end-user’s applications based on their availability, performance, capability, and Quality of Service (QoS) requirements. Various enterprise Clouds can be pooled together to form a federated infrastructure of resource pools (nodes, services, virtual computers). In a federated organisation: (i) every participant gets access to much larger pools of resources; (ii) the peak-load handling capacity of every enterprise Cloud increases without having the need to maintain or administer any additional computing nodes, services, and storage devices; and (iii) the reliability of a enterprise Cloud is enhanced as a result of multiple redundant clouds that can efficiently tackle disaster condition and ensure business continuity. Emerging enterprise Cloud applications and the underlying federated hardware infrastructure (Data Centers) are inherently large, with heterogeneous resource types that may exhibit temporal resource conditions. The unique challenges in efficiently managing a federated Cloud computing environment include: •
•
•
Large scale: composed of distributed components (services, nodes, applications, users, virtualized computers) that combine together to form a massive environment. These days enterprise Clouds consisting of hundreds of thousands of computing nodes are common (Amazon Elastic Compute Cloud, 2008; Google App Engine, 2008; Microsoft Live Mesh, 2008) and hence federating them together leads to a massive scale environment; Resource contention: driven by the resource demand pattern and a lack of cooperation among end-user’s applications, particular set of resources can get swamped with excessive workload, which significantly undermines the overall utility delivered by the system; and Dynamic: the components can leave and join the system at will.
The aforementioned characteristics of the infrastructure accounts to significant development, system integration, configuration, and resource management challenges. Further, the end-users follow a variety of programming models to compose their applications. In other words, in order to efficiently harness the computing power of enterprise Cloud infrastructures (Chu, Nandiminti, Jin, Venugopal, & Buyya, 2007; Amazon Elastic Compute Cloud, 2008; Google App Engine, 2008; Microsoft Live Mesh, 2008), software services that can support high level of scalability, robustness, self-organization, and application composition flexibility are required. This chapter has two objectives. The first is to investigate the challenges as regards to design and development of decentralized, scalable, self-organizing, and federated Cloud computing system. The second is to introduce the Aneka-Federation software system that includes various software services, peer-to-peer resource discovery protocols and resource provisioning methods (Ranjan, 2007; Ranjan, Harwood, & Buyya, 2008) to deal with the challenges in designing decentralized resource management system in a complex, dynamic and heterogeneous enterprise Cloud computing environment. The components of the Aneka-Federation including computing nodes, services, providers and end-users self-organize themselves based on a structured peer-to-peer routing methodology to create a scalable wide-area overlay of enterprise Clouds. In rest of this chapter, the terms Aneka Cloud(s) and Aneka Enterprise Cloud(s) are used interchangeably.
192
Decentralized Overlay for Federation of Enterprise Clouds
The unique features of Aneka-Federation are: (i) wide-area scalable overlay of distributed Aneka Enterprise Clouds (Chu et al., 2007); (ii) realization of a peer-to-peer based decentralized resource discovery technique as a software service, which has the capability to handle complex resource queries; and (iii) the ability to enforce coordinated interaction among end-users through the implementation of a novel decentralized resource provisioning method. This provisioning method is engineered over a peer-to-peer routing and indexing system that has the ability to route, search and manage complex coordination objects in the system. The rest of this chapter is organized as follows: First, the challenges and requirements related to design of decentralized enterprise Cloud overlays are presented. Next, follows a brief introduction of the Aneka Enterprise Cloud system including the basic architecture, key services and programming models. Then, a finer detail related to the Aneka-Federation software system that builds upon the decentralized Content-based services is presented. Comprehensive details on the design and implementation of decentralized Content-based services for message routing, search, and coordinated interaction follows. Next, the experimental case study and analysis based on the test run of two enterprise Cloud applications on the Aneka-Federation system is presented. Finally, this work is put in context with the related works. The chapter ends with a brief conclusion.
DESIGNING DECENTRALIzED ENTERPRISE CLOUD OVERLAY In decentralized organization of Cloud computing systems both control and decisions making are decentralized by nature and where different system components interact together to adaptively maintain and achieve a desired system wide behavior. A distributed Cloud system configuration is considered to be decentralized “if none of the components in the system are more important than the others, in case that one of the component fails, then it is neither more nor less harmful to the system than caused by the failure of any other component in the system”. A fundamental challenge in managing the decentralized Cloud computing system is to maintain a consistent connectivity between the components (self-organization) (Parashar & Hariri, 2007). This challenge cannot be overtaken by introducing a central network model to connect the components, since the information needed for managing the connectivity and making the decisions is completely decentralized and distributed. Further, centralized network model (Zhang, Freschl, & Schopf, 2003) does not scale well, lacks fault-tolerance, and requires expensive server hardware infrastructure. System components can leave, join, and fail in a dynamic fashion; hence it is an impossible task to manage such a network centrally. Therefore, an efficient decentralized solution is mandatory that can gracefully adapt, and scale to the changing conditions. A possible way to efficiently interconnect the distributed system components can be based on structured peer-to-peer overlays. In literature, structured peer-to-peer overlays are more commonly referred to as the Distributed Hash Tables (DHTs). DHTs provide hash table like functionality at the Internet scale. DHTs such as Chord (Stoica, Morris, Karger, Kaashoek, & Balakrishnan, 2001), CAN (Ratnasamy, Francis, Handley, Karp, & Schenker, 2001), Pastry (Rowstron & Druschel, 2001), and Tapestry (Zhao, Kubiatowicz, & Joseph, 2001) are inherently self-organizing, fault-tolerant, and scalable. DHTs provide services that are light-weight and hence, do not require an expensive hardware platform for hosting, which is an important requirement as regards to building and managing enterprise Cloud system that consists of commodity machines. A DHT is a distributed data structure that associates a key with a data.
193
Decentralized Overlay for Federation of Enterprise Clouds
Entries in a DHT are stored as a (key, data) pair. A data can be looked up within a logarithmic overlay routing hops if the corresponding key is known. The effectiveness of the decentralized Cloud computing system depends on the level of coordination and cooperation among the components (users, providers, services) as regards to scheduling and resource allocation. Realizing cooperation among distributed Cloud components requires design and development of the self-organizing, robust, and scalable coordination protocols. The Aneka-Federation system implements one such coordination protocol using the DHT-based routing, lookup and discovery services. The finer details about the coordination protocol are discussed later in the text.
ANEKA ENTERPRISE CLOUD: AN OVERVIEW Aneka (Chu et al., 2007) is a .NET-based service-oriented platform for constructing enterprise Clouds. It is designed to support multiple application models, persistence and security solutions, and communication protocols such that the preferred selection can be changed at anytime without affecting an existing Aneka ecosystem. To create an enterprise Cloud, the resource provider only needs to start an instance of the configurable Aneka container hosting required services on each selected Cloud node. The purpose of the Aneka container is to initialize services and acts as a single point for interaction with the rest of the enterprise Cloud. Figure 1 shows the design of the Aneka container on a single Cloud node. To support scalability, the Aneka container is designed to be lightweight by providing the bare minimum functionality needed for an enterprise Cloud node. It provides the base infrastructure that consists of services for persistence, security (authorization, authentication and auditing), and communication (message handling and dispatching). Every communication within the Aneka services is treated as a message, handled and dispatched through the message handler/dispatcher that acts as a front controller. The Aneka container hosts a compulsory MembershipCatalogue service, which maintains the resource discovery indices (such as a .Net remoting address) of those services currently active in the system. The Aneka container can host any number of optional services that can be added to augment the capabilities of an enterprise Cloud node. Examples of optional services are indexing, scheduling, execution, and storage services. This provides a single, flexible and extensible framework for orchestrating different kinds of enterprise Cloud application models. To support reliability and flexibility, services are designed to be independent of each other in a container. A service can only interact with other services on the local node or other Cloud node through known interfaces. This means that a malfunctioning service will not affect other working services and/ or the container. Therefore, the resource provider can seamlessly configure and manage existing services or introduce new ones into a container. Aneka thus provides the flexibility for the resource provider to implement any network architecture for an enterprise Cloud. The implemented network architecture depends on the interaction of services among enterprise Cloud nodes since each Aneka container on a node can directly interact with other Aneka containers reachable on the network.
194
Decentralized Overlay for Federation of Enterprise Clouds
Figure 1. Design of Aneka container
ANEKA-FEDERATION The Aneka-Federation system self-organizes the components (nodes, services, clouds) based on a DHT overlay. Each enterprise Cloud site in the Aneka-Federation (see Figure 2) instantiates a new software service, called Aneka Coordinator. Based on the scalability requirements and system size, an enterprise Cloud can instantiate multiple Aneka Coordinator services. The Aneka Coordinator basically implements the resource management functionalities and resource discovery protocol specifications. The software design of the Aneka-Federation system decouples the fundamental decentralized interaction of participants from the resource allocation policies and the details of managing a specific Aneka Cloud Service. Aneka-Federation software system utilizes the decentralized Cloud services as regards to efficient distributed resource discovery and coordinated scheduling.
DESIGN AND IMPLEMENTATION Aneka Coordinator software service is composed of the following components:
195
Decentralized Overlay for Federation of Enterprise Clouds
Figure 2. Aneka-Federation network with the coordinator services and Aneka enterprise Clouds
•
•
Aneka services: These include the core services for peer-to-peer scheduling (Thread Scheduler, Task Scheduler, Dataflow Scheduler) and peer-to-peer execution (Thread Executor, Task Executor) provided by the Aneka framework. These services work independently in the container and have the ability to interact with other services such as the P2PMembershipCatalogue through the MessageDispatcher service deployed within each container. Aneka peer: This component of the Aneka Coordinator service loosely glues together the core Aneka services with the decentralized Cloud services. Aneka peer seamlessly encapsulates together the following: Apache Tomcat container (hosting environment and web service front end to the Content-based services), Internet Information Server (IIS) (hosting environment for ASP. Net service), P2PMembershipCatalogue, and Content-based services (After Figure 3 see Figure 4). The basic functionalities of the Aneka peer (refer to Figure 3) include providing services for: (i) Content-based routing of lookup and update messages; and (ii) facilitating decentralized coordination for efficient resource sharing and load-balancing among the Internet-wide distributed Aneka Enterprise Clouds. The Aneka peer service operates at the Core services layer in the layered architecture shown after Figures 5, 6, 7, and 8, in Figure 9.
Figure 4 shows a block diagram of interaction between various components of Aneka Coordinator software stack. The Aneka Coordinator software stack encapsulates the P2PMembershipCatalogue
196
Decentralized Overlay for Federation of Enterprise Clouds
Figure 3. Aneka-Federation over decentralized Cloud services
and Content-based decentralized lookup services. The design components for peer-to-peer scheduling, execution, and membership are derived from the basic Aneka framework components through object oriented software inheritance (see Figure 5, Figure 6, and Figure 7). A UML (Unified Modeling Language) class diagram that displays the core entities within the Aneka Coordinator’s Scheduling service is shown in Figure 5. The main class (refer to Figure 5) that undertakes activities related to application scheduling within the Aneka Coordinator is the P2PScheduling service, which is programmatically inherited from the Aneka’s IndependentScheduling service class. The P2PScheduling service implements the methods for: (i) accepting application submission from client nodes (see [REMOVED SHAPE FIELD] Figure 8); (ii) sending search query to the P2PMembershipCatalogue service; (iii) dispatching application to Aneka nodes (P2PExecution service); and (iv) collecting the application output data. The core programming models in Aneka including Task, Thread, and Dataflow instantiate P2PScheduling service as their main scheduler class. This runtime binding of P2PScheduling service class to different programming models is taken care of by Microsoft .NET platform and Inverse of Control (IoC) (Fowler, 2008) implementation in the Spring .NET framework (Spring.Net, 2008). Similar to P2PScheduling service, the binding of P2PExecution service to specific programming models (such as P2PTaskExecution, P2PThreadExecution) is done by Microsoft .NET platform and IoC implementation in the Spring .NET framework. The interaction between the services (such as P2PTaskExecution and P2PTaskScheduling service) is facilitated by the MessageDispatcher service. The P2PExecution services update their node usage status with the P2PMembershipCatalogue through the P2PExecutorStatusUpdate component (see Figure 6). The core Aneka Framework defines distinct message types to enable seamless interaction between services. The functionality of handling, compiling, and delivering the messages within the Aneka framework is implemented in the MessageDispactcher service. Recall that the MessageDispatcher service is automatically deployed in the Aneka container.
197
Decentralized Overlay for Federation of Enterprise Clouds
Figure 4. A block diagram showing interaction between various components in the Aneka Coordinator software stack
P2PMembershipCatalogue service is the core component that interacts with the Content-based decentralized Cloud services and aids in the organization and management of Aneka-Federation overlay. The UML class design for this service within the Aneka Coordinator is shown in Figure 7. This service accepts resource claim and ticket objects from P2PScheduling and P2PExecution services respectively (refer to Figure 8), which are then posted with the Content-based services hosted in the Apache Tomcat container. The P2PMembershipCatalogue interacts with the components hosted within the Apache Tomcat container (Java implementation) using the SOAP-based web services Application Programming Interfaces (APIs) exposed by the DFPastryManager component (see Figure 7). The Content-based service communicates with the P2PMembershipCatalogue service through an ASP.NET web service hosted within in the IIS container (see Figure 4 or 8). The mandatory services within a Aneka Coordinator that are required to instantiate a fully functional Aneka Enterprise Cloud site includes P2PMembershipCatalogue, P2PExecution, P2PScheduling, .Net web service, and Content-based services (see Figure 8). These services exports a enterprise Cloud site to the federation, and give it capability to accept remote jobs based on its load condition (using their P2PExecution services), and submit local jobs to the federation (through their P2PScheduling services). Figure 8 demonstrates a sample application execution flow in the Aneka-Federation system. Clients
198
Decentralized Overlay for Federation of Enterprise Clouds
Figure 5. Class design diagram of P2PScheduling service
directly connect and submit their application to a programming model specific scheduling service. For instance, a client having an application programmed using Aneka’s Thread model would submit his application to Thread P2PScheduling service (refer to step 1 in Figure 8). Clients discover the point of contact for local scheduling services by querying their domain specific Aneka Coordinator service. On receipt of an application submission message, a P2PScheduling service encapsulates the resource requirement for that application in a resource claim object and sends a query message to the P2PMembershipCatalogue (see step 2 in Figure 8). Execution services (such as the P2PThreadExecution, P2PTaskExecution), which are distributed over different enterprise Clouds and administered by enterprise specific Aneka Coordinator services, update their status by sending a resource ticket object to the P2PMembership Catalogue (see step 3 in Figure 8). A resource ticket object in the Aneka-Federation system abstracts the type of service being offered, the underlying hardware platform, and level of QoS that can be supported. The finer details about the composition and the mapping of resource ticket and claim objects are discussed later in this chapter. The P2PMembershipCatalogue then posts the resource ticket and claim objects with the decentralized Content-based services (see step 4 and 5 in Figure 8). When a resource ticket, issued by a P2PTExecution service, matches with a resource claim object, posted by a P2PScheduling service, the Content-based service sends a match notification to the P2PScheduling service through the P2PMembershipCatalogue (see step 6, 7, 8 in Figure 8). After receiving the notification, the P2PScheduling service deploys its application on the P2PExecution service (see step 9 in Figure 8). On completion of a submitted applica-
199
Decentralized Overlay for Federation of Enterprise Clouds
Figure 6. Class design diagram of P2PExecution service
tion, the P2PExecution service directly returns the output to the P2PScheduling service (see step 10 in Figure 8). (Figure 9 and Figure 10) The Aneka Coordinator service supports the following two inter-connection models as regards to an Aneka Enterprise Cloud site creation (See Figure 9 and Figure 10). First, a resource sharing domain or enterprise Cloud can instantiate a single Aneka-Coordinator service, and let other nodes in the Cloud connect to the Coordinator service. In such a scenario, other nodes need to instantiate only the P2PExecution and P2PScheduling services. These services are dependent on the domain specific Aneka Coordinator service as regards to load update, resource lookup, and membership to the federation (see Figure 11). In second configuration, each node in a resource domain can be installed with all the services within the Aneka Coordinator (see Figure 4). This kind of inter-connection will lead to a true peer-topeer Aneka-Federation Cloud network, where each node is an autonomous computing node and has the ability to implement its own resource management and scheduling decisions. Hence, in this case the Aneka Coordinator service can support completely decentralized Cloud computing environment both within and between enterprise Clouds.
200
Decentralized Overlay for Federation of Enterprise Clouds
Figure 7. Class design diagram of P2PMembershipCatalogue service
CONTENT-BASED DECENTRALIzED CLOUD SERVICES It is aforementioned that the DHT based overlay presents a compelling solution for creating a decentralized network of Internet-wide distributed Aneka Enterprise Clouds. However, DHTs are efficient at handling single-dimensional search queries such as “find all services that match a given attribute value”. Since Cloud computing resources such as enterprise computers, supercomputers, clusters, storage devices, and databases are identified by more than one attribute, therefore a resource search query for these resources is always multi-dimensional. These resource dimensions or attributes include service type, processor speed, architecture, installed operating system, available memory, and network bandwidth. Recent advances in the domain of decentralized resource discovery have been based on extending the existing DHTs with the capability of multi-dimensional data organization and query routing (Ranjan, Harwood, & Buyya, 2008). Our decentralized Cloud management middleware supports peer-to-peer Content-based resource discovery and coordination services for efficient management of distributed enterprise Clouds. The middleware is designed based on a 3-tier layered architecture: the Application layer, Core Services layer, and Connectivity layer (see Figure 9). Cloud services such as the Aneka Coordinator, resource brokers, and schedulers work at the Application layer and insert objects via the Core services layer. The core functionality including the support for decentralized coordinated interaction, and scalable resource dis-
201
Decentralized Overlay for Federation of Enterprise Clouds
Figure 8. Application execution sequence in Aneka-Federation
covery is delivered by the Core Services Layer. The Core services layer, which is managed by the Aneka peer software service, is composed of two sub-layers (see Figure 9): (i) Coordination Service (Ranjan et al., 2007); and (ii) Resource discovery service. The Coordination service component of Aneka peer accepts the coordination objects such as a resource claim and resource ticket. A resource claim object is a multi-dimensional range look-up query (Samet, 2008) (spatial range object), which is initiated by Aneka Coordinators in the system in order to locate the available Aneka Enterprise Cloud nodes or services that can host their client ‘s applications. A resource claim object has the following semantics:
Aneka Service = “P2PThreadExecution” && CPU Type = “Intel” && OSType = “WinXP” && Processor Cores > “1” && Processors Speed > “1.5 GHz” On the other hand, a resource ticket is a multi-dimensional point update query (spatial point object), which is sent by an Aneka Enterprise Cloud to report the local Cloud nodes and the deployed services’ availability status. A resource ticket object has the following semantics:
202
Decentralized Overlay for Federation of Enterprise Clouds
Figure 9. Layered view of the content-based decentralized Cloud services
Aneka Service = “P2PThreadExecution” && CPU Type = “Intel” && OSType = “WinXP” && Processor Cores = “2” && Processors Speed = “3 GHz” Further, both of these queries can specify different kinds of constraints on the attribute values. If a query specifies a fixed value for each attribute then it is referred to as a multi-dimensional point query. However, in case the query specifies a range of values for attributes, then it is referred to as a multidimensional range query. The claim and ticket objects encapsulate coordination logic, which in this case is the resource provisioning logic. The calls between the Coordination service and the Resource Discovery service are made through the standard publish/subscribe technique. Resource Discovery service is responsible for efficiently mapping these complex objects to the DHT overlay. The Resource Discovery service organizes the resource attributes by embedding a logical publish/ subscribe index over a network of distributed Aneka peers. Specifically, the Aneka peers in the system create a DHT overlay that collectively maintains the logical index to facilitate a decentralized resource discovery process. The spatial publish/subscribe index builds a multi-dimensional attribute space based on the Aneka Enterprise Cloud node’s resource attributes, where each attribute represents a single dimension. The multi-dimensional spatial index assigns regions of space to the Aneka peer. The calls between Core services layer and Connectivity layer are made through standard DHT primitives such
203
Decentralized Overlay for Federation of Enterprise Clouds
Figure 10. Resource claim and ticket object mapping and coordinated scheduling across Aneka Enterprise Cloud sites. Spatial resource claims {T1, T2, T3, T4}, index cell control points {A, B, C, D}, spatial point tickets {l, s} and some of the spatial hashings to the Pastry ring, i.e. the d-dimensional (spatial) coordinate values of a cell’s control point is used as the Pastry key. For this Figure fmin =2, dim = 2.
as put (key, value), get (key) that are defined by the peer-to-peer Common Application Programming Interface (API) specification 0. There are different kinds of spatial indices 0 such as the Space Filling Curves (SFCs) (including the Hilbert curves, Z-curves), k-d tree, MX-CIF Quad tree and R*-tree that can be utilized for managing, routing, and indexing of objects by resource discovery service at Core services layer. Spatial indices are well suited for handling the complexity of Cloud resource queries. Although some spatial indices can have issues as regards to routing load-balance in case of a skewed attribute set, all the spatial indices are generally scalable in terms of the number of hops traversed and messages generated while searching and routing multi-dimensional/spatial claim and ticket objects. Resource claim and ticket object mapping: At the Core services layer, a spatial index that assigns regions of multi-dimensional attribute space to Aneka peers has been implemented. The MX-CIF Quadtree spatial hashing technique (Egemen, Harwood, & Samet, 2007) is used to map the logical
204
Decentralized Overlay for Federation of Enterprise Clouds
Figure 11. Aneka-Federation test bed distributed over 3 departmental laboratories
multi-dimensional control point (point C in Figure 10 represents a 2-dimensional control point) onto a Pastry DHT overlay. If an Aneka peer is assigned a region in the multi-dimensional attribute space, then it is responsible for handling all the activities related to the lookups and updates that intersect with the region of space. Figure 10 depicts a 2-dimensional Aneka resource attribute space for mapping resource claim and ticket objects. The attribute space resembles a mesh-like structure due to its recursive division process. The index cells, resulted from this process, remain constant throughout the life of a d-dimensional attribute space and serve as the entry points for subsequent mapping of claim and ticket objects. The number of index cells produced at the minimum division level, fmin is always equal to (fmin) dim , where dim is the dimensionality of the attribute space. These index cells are called base index cells and they are initialized when the Aneka Peers bootstrap to the federation network. Finer details on the recursive subdivision technique can be found in (Egemen et al., 2007). Every Aneka Peer in the federation has the basic information about the attribute space coordinate values, dimensions and minimum division levels. Every cell at the fmin level is uniquely identified by its centroid, termed as the control point. Figure 10 shows four control points A, B, C, and D. A DHT hashing (cryptographic functions such as SHA1/2) method is utilized to map the responsibility of managing control points to the Aneka Peers. In a 2-dimensional setting, an index cell i = (x1, y1, x2, y2), and its control point are computed as ((x2-x1)/2, (y2-y1)/2). The spatial hashing technique takes two input parameters, SpatialHash (control point coor-
205
Decentralized Overlay for Federation of Enterprise Clouds
dinates, object’s coordinates), in terms of DHT common API primitive that can be written as put (Key, Value), where the cryptographic hash of the control point acts as the Key for DHT overlay, while Value is the coordinate values of the resource claim or ticket object to be mapped. In Figure 10, the Aneka peer at Cloud s is assigned index cell i through the spatial hashing technique, which makes it responsible for managing all objects that map to the cell i (Claim T2, T3, T4 and Ticket s). For mapping claim objects, the process of mapping index cells to the Aneka Peers depends on whether it is spatial point object or spatial range object. The mapping of point object is simple since every point is mapped to only one cell in the attribute space. For spatial range object (such as Claims T2, T3 or T4), the mapping is not always singular because a range object can cross more than once index cell (see Claim T5 in Figure 10). To avoid mapping a spatial range object to all the cells that it intersects, which can create many duplicates, a mapping strategy based on diagonal hyperplane 0 in the attribute space is implemented. This mapping involves feeding spatial range object coordinate values and candidate index as inputs to a mapping function, Fmap (spatial object, candidate index cells). An Aneka Peer service uses the index cell(s) currently assigned to it and a set of known base index cells as candidate cells, which are obtained at the time of bootstrapping into the federation. The Fmap returns the index cells and their control points to which the given spatial range object should be stored with. Next, these control points and the spatial object is given as inputs to function SpatialHash(control point, object), which in connection with the Connectivity layer generates DHT Ids (Keys) and performs routing of claim/ticket objects to the Aneka Peers. Similarly, the mapping process of a ticket object also involves the identification of the intersection index cells in the attribute space. A ticket is always associated with a region (Gupta, Sahin, Agarwal, & Abbadi, 2004) and all cells that fall fully or partially within the region are selected to receive the corresponding ticket. The calculation of the region is based upon the diagonal hyperplane of the attribute space. Coordinated load balancing: Both resource claim and ticket objects are spatially hashed to an index cell i in the multi-dimensional Aneka services’ attribute space. In Figure 10, resource claim object for task T1 is mapped to index cell A, while for T2, T3, and T4, the responsible cell is i with control point value C. Note that, these resource claim objects are posted by P2PScheduling services (Task or Thread) of Aneka Cloud nodes. In Figure 10, scheduling service at Cloud p posts a resource claim object which is mapped to index cell i. The index cell i is spatially hashed to an Aneka peer at Cloud s. In this case, Cloud s is responsible for coordinating the resource sharing among all the resource claims that are currently mapped to the cell i. Subsequently, Cloud u issues a resource ticket (see Figure 10) that falls under a region of the attribute space currently required by the tasks T3 and T4. Next, the coordination service of Aneka peer at Cloud s has to decide which of the tasks (either T3 or T4 or both) is allowed to claim the ticket issues by Cloud u. The load-balancing decision is based on the principle that it should not lead to over-provisioning of resources at Cloud u. This mechanism leads to coordinated load-balancing across Aneka Enterprise Clouds and aids in achieving system-wide objective function, while at the same time preserving the autonomy of the participating Aneka Enterprise Clouds. The examples in Table 1 are list of resource claim objects that are stored with an Aneka peer’s coordination service at time T = 700 secs. Essentially, the claims in the list arrived at a time <= 700 and wait for a suitable ticket object that can meet their application’s requirements (software, hardware, service type). Table 2 depicts a ticket object that has arrived at T = 700. Following the ticket arrival, the coordination service undertakes a procedure that allocates the ticket object among the list of matching claims. Based on the Cloud node’s attribute specification, both Claim 1 and Claim 2 match the ticket issuing Cloud
206
Decentralized Overlay for Federation of Enterprise Clouds
Table 1. Claims stored with an Aneka Peer service at time T Time 300
Claim ID Claim 1
Service Type
Speed (GHz)
P2PThreadExecution
400
Claim 2
P2PTaskExecution
500
Claim 3
P2PThreadExecution
>2
Processors 1
Type Intel
>2
1
Intel
> 2.4
1
Intel
node’s configuration. As specified in the ticket object, there is currently one processor available within the Cloud 2, which means that at this time only Claim 1 can be served. Following this, the coordination service notifies the Aneka-Coordinator, which has posted the Claim 1. Note that Claims 2 and 3 have to wait for the arrival of tickets that can match their requirements. The Connectivity layer is responsible for undertaking a key-Based routing in the DHT overlay, where it can implement the routing methods based on DHTs, such as Chord, CAN, and Pastry. The actual implementation protocol at this layer does not directly affect the operations of the Core services layer. In principle, any DHT implementation at this layer could perform the desired task. DHTs are inherently self-organizing, fault-tolerant, and scalable. At the Connectivity layer, our middleware utilizes the open source implementation of Pastry DHT known as the FreePastry (2008). FreePastry offers a generic, scalable and efficient peer-to-peer routing framework for the development of decentralized Cloud services. FreePastry is an open source implementation of well-known Pastry routing substrate. It exposes a Key-based Routing (KBR) API and given the Key K, Pastry routing algorithm can find the peer responsible for this key in logb n messages, where b is the base and n is the number of Aneka Peers in the network. Nodes in a Pastry overlay form a decentralized, self-organising and fault-tolerant circular network within the Internet. Both data and peers in the Pastry overlay are assigned Ids from 160-bit unique identifier space. These identifiers are generated by hashing the object’s names, a peer’s IP address or public key using the cryptographic hash functions such as SHA-1/2. FreePastry is currently available under BSD-like license. FreePastry framework supports the P2P Common API specification proposed in the paper (Dabek, Zhao, Druschel, Kubiatowicz, & Stoica, 2003).
ExPERIMENTAL EVALUATION AND DISCUSSION In this section, we evaluate the performance of the Aneka-Federation software system by creating a resource sharing network that consists of 5 Aneka Enterprise Clouds (refer to Figure 11). These Aneka Enterprise Clouds are installed and configured in three different Laboratories (Labs) within the Computer Science and Software Engineering Department, The University of Melbourne. The nodes in these Labs
Table 2: Ticket Published with an Aneka Peer service at time T Time 700
Cloud ID Cloud 2
Service Type P2PThreadExecution
Speed (GHz) 2.7
Processors 1 (available)
Type Intel
207
Decentralized Overlay for Federation of Enterprise Clouds
are connected through a Local Area Network (LAN). The LAN connection has a data transfer bandwidth of 100 Mb/Sec (megabits per seconds). Next, the various parameters and application characteristics related to this study are briefly described. Aneka enterprise cloud configuration: Each Aneka Cloud in the experiments is configured to have 4 nodes out of which, one of the nodes instantiates the Aneka-Coordinator service. In addition to the Aneka Coordinator service, this node also hosts the other optional services including the P2PScheduling (for Thread and Task models) and P2PExecution services (for Thread and Task models). The remaining 3 nodes are configured to run the P2PExecution services for Task and Thread programming models. These nodes connect and communicate with the Aneka-Coordinator service through .Net remoting messaging APIs. The P2PExecution services periodically update their usage status with the Aneka-Coordinator service. The update delay is configurable parameter with values in milliseconds or seconds. The nodes across different Aneka Enterprise Clouds update their status dynamically with the decentralized Content-based services. The node status update delays across the Aneka Enterprise Clouds are uniformly distributed over interval [5, 40] seconds. FreePastry network configuration: Both Aneka Peers’ nodeIds and claim/ticket objectIds are randomly assigned from and uniformly distributed in the 160-bit Pastry identifier space. Every Contentbased service is configured to buffer maximum of 1000 messages at a given instance of time. The buffer size is chosen to be sufficiently large such that the FreePastry does not drop any messages. Other network parameters are configured to the default values as given in the file freepastry.params. This file is provided with the FreePastry distribution. Spatial index configuration: The minimum division fmin of logical d-dimensional spatial index that forms the basis for mapping, routing, and searching the claim and ticket objects is set to 3, while the maximum height of the spatial index tree, fmax is constrained to 3. In other words, the division of the d-dimensional attribute is not allowed beyond fmin. This is done for simplicity, understanding the load balancing issues of spatial indices (Egemen et al., 2007) with increasing fmax is a different research problem and is beyond scope of this chapter. The index space has provision for defining claim and ticket objects that specify the Aneka nodes/service’s characteristics in 4 dimensions including number of Aneka service type, processors, processor architecture, and processing speed. The aforementioned spatial index configuration results into 81(34) index cells at fmin level. On an average, 16 index cells are hashed to an Aneka Peer in a network of 5 Aneka Coordinators. Claim and ticket object’s spatial extent: Ticket objects in the Aneka-Federation express equality constraints on an Aneka node’s hardware/software attribute value (e.g. =). In other words, ticket objects are always d-dimensional (spatial) point query for this study. On the other hand, the claim objects posted by P2PScheduling services have their spatial extent in d dimensions with both, range and fixed constraint (e.g. >=, <=) for the attributes. The spatial extent of a claim object in different attribute dimension is controlled by the characteristic of the node, which is hosting the P2PScheduling service. Attributes including Aneka service type, processor architecture, and number of processors are fixed, i.e. they are expressed as equality constraints. The value for processing speed is expressed using >= constraints, i.e. search for the Aneka services, which can process application atleast as fast as what is available on the submission node. However, the P2PScheduling services can create claim objects with different kind of constraints, which can result in different routing, searching, and matching complexity. Studying this behavior of the system is beyond the scope of this chapter. Application models: Aneka supports composition and execution of application programmers using different models (Vecchiola & Chu, 2008) to be executed on the same enterprise Cloud infrastructure. The
208
Decentralized Overlay for Federation of Enterprise Clouds
experimental evaluation in this chapter considers simultaneous execution of applications programmed using Task and Thread models. The Task model defines an application as a collection of one or more tasks, where each task represents an independent unit of execution. Similarly, the Thread model defines an application as a collection of one or more independent threads. Both models can be successfully utilized to compose and program embarrassingly parallel programs (parameter sweep applications). The Task model is more suitable for cloud enabling the legacy applications, while the Thread model fits better for implementing and architecting new applications, algorithms on clouds since it gives finer degree of control and flexibility as regards to runtime control. To demonstrate the effectiveness of the Aneka-Federation platform with regards to: (i) ease of heterogeneous application composition flexibility; (ii) different programming model supportability; and (iii) concurrent scheduling feasibility of heterogeneous applications on shared Cloud computing infrastructure, the experiments are run based on the following applications: •
•
Persistence of Vision Raytracer (2008): This application is cloud enabled using the Aneka Task programming model. POV-Ray is an image rendering application that can create very complex and realistic three dimensional models. Aneka POV-Ray application interface allows the selection of a model, the dimension of the rendered image, and the number of independent tasks into which rendering activities have to be partitioned. The task partition is based on the values that a user specifies for parameter rows and columns on the interface. In the experiments, the values for the rows and the columns are varied over the interval [5 x 5, 13 x 13] in steps of 2. Mandelbrot Set (2008): Mathematically, the Mandelbrot set is an ordered collection of points in the complex plane, the boundary of which forms a fractal. Aneka implements and cloud enables the Mandelbrot fractal calculation using the Thread programming model. The application submission interface allows the user to configure number of horizontal and vertical partitions into which the fractal computation can be divided. The number of independent thread units created is equal to the horizontal x vertical partitions. For evaluations, we vary the values for horizontal and vertical parameters over the interval [5 x 5, 13 x 13 ] in steps of 2. This configuration results in 5 observation points.
Results and Discussion To measure the performance of Aneka-Federation system as regards to scheduling, we quantify the response time metric for the POV-Ray and Mandelbrot applications. The response time for an application is computed by subtracting the output arrival time of the last task/thread in the execution list from the time at which the application is submitted. The observations are made for different application granularity (sizes) as discussed in the last Section. Figure 12 depicts the results for response time in seconds with increasing granularity for the POVRay application. The users at Aneka Cloud 1, 3, 4 submit the applications to their respective Aneka Coordinator services (refer to the Figure 11). The experiment results show that the POV-Ray application submitted at Aneka Cloud 1 experienced comparatively lesser response times for its POV-Ray tasks as compared to the ones submitted at Aneka Cloud 3 and 4. The fundamental reasons behind this behavior of system is that the spatial extent and attribute constraints of the resource claim objects posted by the P2PTaskScheduling service at Aneka Cloud 1. As shown in Figure 11, every Aneka Cloud offers processors of type “Intel” with varying speed. Based on the in the previous Section, the processing speed
209
Decentralized Overlay for Federation of Enterprise Clouds
Figure 12. POV-Ray application: Response time (secs) vs. problem size
is expressed using >= constraints, which means that the application submitted in the Aneka Enterprise Clouds, 1 and 2 (processing speed = 2.4 GHz), can be executed on any of the nodes in the enterprise Clouds 1, 2, 3, 4, and 5. However, the application submitted at Aneka Clouds 3 and 4 can be executed only on Clouds 3, 4, and 5. Accordingly, the application submitted in Aneka Cloud 3 can only be processed locally as the spatial dimension and processing speed for the resource claim objects specifies constraints as >= 3.5 GHz. Due to these spatial constraints on the processing speed attribute value, the application in different Clouds gets access to varying Aneka node pools that result in different levels of response times.
Figure 13. Mandelbrot application: Response time (Secs) vs. problem size
210
Decentralized Overlay for Federation of Enterprise Clouds
Figure 14. P2PTaskExecution service: Time (secs) vs. number of jobs completed
For the aforementioned arguments, it can be seen in Figure 12 and Figure 13 (Mandelbrot applications) that applications at Aneka Clouds 1 and 2 have relatively better response times as compared to the ones submitted at Aneka Cloud 3, 4, and 5. Figure 14 and Figure 15 present the results for the total number of jobs processed in different Aneka Clouds by their P2PTaskExecution and P2PThreadExectuion services. The results show that the P2PTaskExecution and P2PThreadExecution services hosted within the Aneka Clouds 3, 4, and 5 processes relatively more jobs as compared to those hosted within Aneka Clouds 1 and 2. This happens due to the spatial constraint on the processing speed attribute value in the resource claim object posted by different P2PScheduling (Task/Thread) services across the Aneka Clouds. As Aneka Cloud 5 offers the fastest processing speed (within the spatial extent of all resource claim objects in the system), it Figure 15. P2PThreadExecution service: Time (secs) vs. number of jobs completed
211
Decentralized Overlay for Federation of Enterprise Clouds
Figure 16. Enterprise Cloud Id vs. job %
processes more jobs as compared to other Aneka Clouds in the federation (see Figure 14 and Figure 15). Thus, in the proposed Aneka-Federation system, the spatial extent for resource attribute values specified by the P2PScheduling services directly controls the job distribution and application response times in the system. Figure 16 shows the aggregate percentage of task and thread jobs processed by the nodes of the different Aneka Clouds in the federation. As mentioned in our previous discussions, Aneka Clouds 3, 4, and 5 ends up processing larger percentage for both Task and Thread application composition models. Together they process approximately 140% of total 200% jobs (100% task + 100% thread) in the federation.
RELATED WORK Volunteer computing systems including SETI@home (Anderson, Cobb, Korpela, Lebofsky, & Werthimer, 2002) and BOINC (Anderson, 2004) are the first generation implementation of public resource computing systems. These systems are engineered on the traditional master/worker model, wherein a centralized scheduler/coordinator is responsible for scheduling, dispatching tasks and collecting data from the participant nodes in the Internet. These systems do not provide any support for multi-application and programming models, a capability which is inherited from the Aneka to the Aneka-Federation platform. Unlike SETI@home and BOINC, Aneka-Federation creates a decentralized overlay of Aneka Enterprise Clouds. Further, Aneka-Federation allows submission, scheduling, and dispatching of application from any Aneka-Coordinator service in the system, thus giving every enterprise Cloud site autonomy and flexibility as regards to decision making. OurGrid (Andrade et al., 2003) is a peer-to-peer middleware infrastructure for creating an Internetwide enterprise Grid computing platform. The message routing and communication between the OurGrid sites is done via broadcast messaging primitive based on the JXTA (Gong, 2001) substrate. ShareGrid
212
Decentralized Overlay for Federation of Enterprise Clouds
Project (2008) extends the OurGrid infrastructure with fault-tolerance scheduling capability by replication tasks across a set of available nodes. In contrast to the OurGrid and the ShareGrid, Aneka-Federation implements a coordinated scheduling protocol by embedding a d-dimensional index over a DHT overlay, which makes the system highly scalable and guarantees deterministic search behavior (unlike JXTA). Further, the OurGrid system supports only the parameter sweep application programming model, while the Aneka-Federation supports more general programming abstractions including Thread, Task, and Dataflow. Peer-to-Peer Condor flock system (Butt et al., 2003) aggregates Internet-wide distributed condor work pools based on the Pastry overlay (Rowstron et al., 2001). The site managers in the Pastry overlay accomplish the load-management by announcing their available resources to all sites, who’s Identifiers (IDs) appear in the routing table. An optimized version of this protocol proposes recursively propagating the load-information to the sites who’s IDs are indexed by the contacted site’s routing table. The scheduling coordination in an overlay is based on probing each site in routing table for resource availability. The probe message propagates recursively in the network until a suitable node is located. In the worst case, the number of messages generated due to recursive propagation can result into broadcast communication. In contrast, Aneka-Federation implements more scalable, deterministic and flexible coordination protocol by embedding a logical d-dimensional index over DHT overlay. The d-dimensional index gives the Aneka-Federation the ability to perform deterministic search for Aneka services, which are defined based on the complex node attributes (CPU type, speed, service type, utilization). XtermWeb-CH (Abdennadher & Boesch, 2005) extends the XtermWeb project (Fedak, Germain, Neri, & Cappello, 2002) with the functionalities such as peer-to-peer communication among the worker nodes. However, the core scheduling and management component in XtermWeb-CH, which is called the coordinator, is a centralized service that has a limited scalability. G2-P2P (Mason & Kelly, 2005) uses the Pastry framework to create a scalable cycle-stealing framework. The mappings of objects to nodes are done via Pastry routing method. However, the G2-P2P system does not implement any specific scheduling or load-balancing algorithm that can take into account the current application load on the nodes and based on that perform runt-time load-balancing. In contrast, the Aneka-Federation realizes a truly decentralized, cooperative and coordinated application scheduling service that can dynamically allocate applications to the Aneka services/nodes without over-provisioning them.
CONCLUSION AND FUTURE DIRECTIONS The functionality exposed by the Aneka-Federation system is very powerful, and our experimental results on real test-bed prove that it is a viable technology for federating high throughput Aneka Enterprise Cloud systems. One of our immediate goals is to support substantially larger Aneka-Federation setups than the ones used in the performance evaluations. We intend to provide support for composing more complex application models such as e-Research workflows that have both compute and data node requirement. The resulting Aneka-Federation infrastructure will enable new generation of application composition environment where the application components, Enterprise Clouds, services, and data would interact as peers. There are several important aspects of this system that require further implementation and future research efforts. One such aspect being developing fault-tolerant (self-healing) application scheduling algorithms that can ensure robust executions in the event of concurrent failures and rapid join/leave
213
Decentralized Overlay for Federation of Enterprise Clouds
operations of enterprise Clouds/Cloud nodes in decentralized Aneka-Federation overlay. Other important design aspect that we would like to improve is ensuring a truly secure (self-protected) Aneka-Federation infrastructure based on peer-to-peer reputation and accountability models.
ACKNOWLEDGMENT The authors would like to thank Australian Research Council (ARC) and the Department of Innovation, Industry, Science, and Research (DIISR) for supporting this research through the Discovery Project and International Science Linkage grants respectively. We would also like to thank Dr. Tejal Shah, Dr. Sungjin Choi, Dr. Christian Vecchiola, and Dr. Alexandre di Costanzo for proofreading the initial draft of this chapter. The chapter is partially derived from our previous publications (Ranjan, 2007).
REFERENCES Abdennadher, N., & Boesch, R. (2005). Towards a peer-to-peer platform for high performance computing. In HPCASIA’05 Proceedings of the Eighth International Conference in High-Performance Computing in Asia-Pacific Region, (pp. 354-361). Los Alamitos, CA: IEEE Computer Society. Retrieved from http:// doi.ieeecomputersociety.org/10.1109/HPCASIA.2005.98 Amazon Elastic Compute Cloud. (2008, November). Retrieved from http://www.amazon.com/ec2 Anderson, D. P. (2004). BOINC: A system for public-resource computing and storage. In Grid’04 Proceedings of the Fifth IEEE/ACM International Workshop on Grid Computing, (pp. 4-10). Los Alamitos, CA: IEEE Computer Society. Retrieved from http://dx.doi.org/10.1109/GRID.2004.14 Anderson, D. P., Cobb, J., Korpela, E., Lebofsky, M., & Werthimer, D. (2002). SETI@home: An experiment in public-resource computing. Communications of the ACM, 45(11), 56-61. New York: ACM Press. Retrieved from http://doi.acm.org/10.1145/581571.581573 Andrade, N., Cirne, W., Brasileiro, F., & Roisenberg, R. (2003, October). OurGrid: An approach to easily assemble grids with equitable resource sharing. In JSSPP’03 Proceedings of the 9th Workshop on Job Scheduling Strategies for Parallel Processing (LNCS). Berlin/Heidelberg, Germany: Springer. doi: 10.1007/10968987 Butt, A. R., Zhang, R., & Hu, Y. C. (2003). A self-organizing flock of condors. In SC ’03 Proceedings of the ACM/IEEE Conference on Supercomputing, (p. 42). Los Alamitos, CA: IEEE Computer Society. Retrieved from http://doi.ieeecomputersociety.org/10.1109/SC.2003.10031 Buyya, R., Yeo, C. S., & Venugopal, S. (2008, September). Market-oriented cloud computing: vision, hype, and reality for delivering it services as computing utilities. In HPCC’08 Proceedings of the 10th IEEE International Conference on High Performance Computing and Communications. Los Alamitos, CA: IEEE CS Press.
214
Decentralized Overlay for Federation of Enterprise Clouds
Chu, X., Nadiminti, K., Jin, C., Venugopal, S., & Buyya, R. (2007, December). Aneka: Next-generation enterprise grid platform for e-science and e-business applications, e-Science’07: In Proceedings of the 3rd IEEE International Conference on e-Science and Grid Computing, Bangalore, India (pp. 151-159). Los Alamitos, CA: IEEE Computer Society Press. For more information, see http://doi.ieeecomputersociety.org/10.1109/E-SCIENCE.2007.12 Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., & Stoica, I. (2003). Towards a common API for structured peer-to-peer overlays. In IPTPS03 Proceedings of the 2nd International Workshop on Peerto-Peer Systems, (pp. 33-44). Heidelberg, Germany: SpringerLink. doi: 10.1007/b11823 Fedak, G., Germain, C., Neri, V., & Cappello, F. (2002, May). XtremWeb: A generic global computing system. In CCGRID’01: Proceeding of the First IEEE Conference on Cluster and Grid Computing, workshop on Global Computing on Personal Devices, Brisbane, (pp. 582-587). Los Alamitos, CA: IEEE Computer Society. Retrieved from http://doi.ieeecomputersociety.org/10.1109/CCGRID.2001.923246 Fowler, M. (2008, November). Inversion of control containers and the dependency injection pattern. Retrieved from http://www.martinfowler.com/articles/injection.html FreePastry. (2008, November). Retrieved from http://freepastry.rice.edu/FreePastry Gong, L. (2001, June). JXTA: A network programming environment. IEEE Internet Computing, 5(3), 88-95. Los Alamitos, CA: IEEE Computer Society. Retrieved from http://doi.ieeecomputersociety. org/10.1109/4236.93518 Google App Engine. (2008, November). Retrieved from http://appengine.google.com Gupta, A., Sahin, O. D., Agarwal, D., & El Abbadi, A. (2004). Meghdoot: Content-based publish/ subscribe over peer-to-peer networks. In Middleware’04 Proceedings of the 5th ACM/IFIP/USENIX International Conference on Middleware, (pp. 254-273). Heidelberg, Germany: SpringerLink. doi: 10.1007/b101561. Luther, A., Buyya, R., Ranjan, R., & Venugopal, S. (2005, June). Alchemi: A. NET-based enterprise grid computing system, In ICOMP’05 Proceedings of the 6th International Conference on Internet Computing, Las Vegas, USA. Mandelbrot Set. (2008, November). Retrieved from http://mathworld.wolfram.com/MandelbrotSet. html. Mason, R., & Kelly, W. (2005). G2-p2p: A fully decentralized fault-tolerant cycle-stealing framework. In R. Buyya, P. Coddington, and A. Wendelborn, (Eds.), In AusGrid’05 Australasian Workshop on Grid Computing and e-Research, Newcastle, Australia, (Vol. 44 of CRPIT, pp. 33-39). Microsoft Live Mesh. (2008, November). Retrieved from http://www.mesh.com. Parashar, M., & Hariri, S. (Eds.). (2007). Autonomic computing: Concepts, infrastructures, and applications. Boca Raton, FL: CRC Press, Taylor and Francis Group. Persistence of Vision Raytracer. (2008, November). Retrieved from http://www.povray.org
215
Decentralized Overlay for Federation of Enterprise Clouds
Ranjan, R. (2007, July). Coordinated resource provisioning in federated grids. Doctoral thesis, The University of Melbourne, Australia. Ranjan, R., Harwood, A., & Buyya, R. (2008, July). Peer-to-peer resource discovery in global grids: A tutorial. IEEE Communication Surveys and Tutorials (COMST), 10(2), 6-33. New York: IEEE Communications Society Press. doi:doi:10.1109/COMST.2008.4564477 Ranjan, R., Harwood, A., & Buyya, R. (2008). Coordinated load management in peer-to-peer coupled federated grid systems. (Technical Report GRIDS-TR-2008-2). Grid Computing and Distributed Systems Laboratory, The University of Melbourne, Australia. doi: http://www.gridbus.org/reports/CoordinatedGrid2007.pdf Ratnasamy, S., Francis, P., Handley, M., Karp, R., & Schenker, S. (2001). A scalable content-addressable network. In SIGCOMM’01 Proceedings of the 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, (pp. 161-172). New York: ACM Press. Retrieved from http://doi.acm.org/10.1145/ 383059.383072 Rowstron, A., & Druschel, P. (2001). Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. In Middleware’01 Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms, (pp. 329-350). Heidelberg, Germany: SpringerLink. doi: 10.1007/3-540-45518-3 Samet, H. (2008, November). The design and analysis of spatial data structures. New York: AddisonWesley Publishing Company. ShareGrid Project. (2008, November). Retrieved from http://dcs.di.unipmn.it/sharegrid. Spring.NET. (2008, November). Retrieved from http://www.springframework.net. Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., & Balakrishnan, H. (2001). Chord: A scalable peerto-peer lookup service for internet applications. In SIGCOMM’01 Proceedings of the 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, (pp. 149 – 160). New York: ACM Press. Retrieved from http://doi.acm.org/10.1145/383059.383071 Tanin, E., Harwood, A., & Samet, H. (2007). Using a distributed quadtree index in peer-to-peer networks. [Heidelberg, Germany: SpringerLink.]. The VLDB Journal, 16(2), 165–178. doi:. doi:10.1007/ s00778-005-0001-y Vecchiola, C., & Chu, X. (2008). Aneka tutorial series on developing task model applications. (Technical Report). Grid Computing and Distributed Systems Laboratory, The University of Melbourne, Australia. Zhang, X., Freschl, J. L., & Schopf, J. M. (2003, June). A performance study of monitoring and information services for distributed systems. In HPDC’03: Proceedings of the Twelfth International Symposium on High Performance Distributed Computing, (pp. 270-281). Los Alamitos, CA: IEEE Computer Society Press. Zhao, B. Y., Kubiatowicz, J. D., & Joseph, A. D. (2001, April). Tapestry: An infrastructure for Faulttolerant wide-area location and routing. Technical Report UCB/CSD-01-1141, UC Berkeley, USA.
216
Decentralized Overlay for Federation of Enterprise Clouds
KEY TERMS AND DEFINITIONS Enterprise Cloud: An enterprise Cloud is a type of computing infrastructure that consists of a collection of inter-connected computing nodes, virtualized computers, and software services that are dynamically provisioned among the competing end-user’s applications based on their availability, performance, capability, and Quality of Service (QoS) requirements. Aneka-Federation: The Aneka-Federation integrates numerous small scale Aneka Enterprise Cloud services and nodes that are distributed over multiple control and enterprise domains as parts of a single coordinated resource leasing abstraction. Overlay Networking: A logical inter-connection of services, nodes, devices, sensors, instruments, and data hosts at application layer (under TCP/IP model) over an infrastructure of physical network routing systems such as the Internet or Local Area Network (LAN). In overlays, the routing and forwarding of messages between services is done on the basis of their relationship in the logical space, while the messages are actually transported through the physical links. Decentralized Systems: A distributed Cloud system configuration is considered to be decentralized if none of the components in the system are more important than the others, in case that one of the component fails, then it is neither more nor less harmful to the system than caused by the failure of any other component in the system. Distributed Hash Table (DHT): A DHT is a data structure that associates unique index with a data. Entries in the DHTs are stored as (index, data) pair. A data can be looked up within a logarithmic overlay routing hops and messages bound if the corresponding index is known. DHTs are self-managing in their behavior as they can dynamically adapt to leave, join and failure of nodes or services in the system. Recently, DHTs have been applied to build Internet scale systems that involve hundreds of thousands of components (node, service, data, and file). Resource Discovery: Resource discovery activity involve searching for the appropriate service, node, or data type that match the requirements of applications such as file sharing, Grid applications, Cloud applications etc. The resource discovery methods can be engineered based on various network models including centralized, decentralized, and hierarchical with varying degree of scalability, fault-tolerance, and network performance. Multi-Dimensional Queries: Complex web services, Grid resource characteristics, and Cloud services are commonly represented by a number of attributes such as service type, hardware (processor type, speed), installed software (libraries, operating system), service name, security (authentication and authorization control); efficiently discovering the aforementioned services with deterministic guarantees in decentralized and scalable manner requires lookup queries to encapsulate search values for each attribute (search dimension) . The search is resolved by satisfying the constraints for the values expressed in each dimension, hence resulting in multi-dimensional queries that search for values in a virtual space that has multiple dimensions (x, y, z…).
ENDNOTE 1
3rd generation enterprise Grids are exhibiting properties that are commonly envisaged in Cloud computing systems.
217
Section 3
Programming Models and Tools
219
Chapter 10
Reliability and Performance Models for Grid Computing Yuan-Shun Dai University of Electronics Science Technology of China, China & University of Tennessee, Knoxville, USA Jack Dongarra University of Tennessee, Knoxville, USA; Oak Ridge National Laboratory, USA; & University of Manchester, UK
ABSTRACT Grid computing is a newly developed technology for complex systems with large-scale resource sharing, wide-area communication, and multi-institutional collaboration. It is hard to analyze and model the Grid reliability because of its largeness, complexity and stiffness. Therefore, this chapter introduces the Grid computing technology, presents different types of failures in grid system, models the grid reliability with star structure and tree structure, and finally studies optimization problems for grid task partitioning and allocation. The chapter then presents models for star-topology considering data dependence and treestructure considering failure correlation. Evaluation tools and algorithms are developed, evolved from Universal generating function and Graph Theory. Then, the failure correlation and data dependence are considered in the model. Numerical examples are illustrated to show the modeling and analysis.
INTRODUCTION Grid computing (Foster & Kesselman, 2003) is a newly developed technology for complex systems with large-scale resource sharing, wide-area communication, and multi-institutional collaboration etc, see e.g. Kumar (2000), Das et al. (2001), Foster et al. (2001, 2002) and Berman et al. (2003). Many experts believe that the grid technologies will offer a second chance to fulfill the promises of the Internet. The real and specific problem that underlies the Grid concept is coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations (Foster et al., 2001). The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources. This is required by a range of collaborative problem-solving and resourceDOI: 10.4018/978-1-60566-661-7.ch010
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Reliability and Performance Models for Grid Computing
brokering strategies emerging in industry, science, and engineering. This sharing is highly controlled by the resource management system (Livny & Raman, 1998), with resource providers and consumers defining what is shared, who is allowed to share, and the conditions under which the sharing occurs. Recently, the Open Grid Service Architecture (Foster et al., 2002) enables the integration of services and resources across distributed, heterogeneous, dynamic, virtual organizations. A grid service is desired to complete a set of programs under the circumstances of grid computing. The programs may require using remote resources that are distributed. However, the programs initially do not know the site information of those remote resources in such a large-scale computing environment, so the resource management system (the brain of the grid) plays an important role in managing the pool of shared resources, in matching the programs to their requested resources, and in controlling them to reach and use the resources through wide-area network. The structure and functions of the resource management system (RMS) in the grid have been introduced in details by Livny & Raman (1998), Cao et al. (2002), Krauter et al. (2002) and Nabrzyski et al. (2003). Briefly stated, the programs in a grid service send their requests for resources to the RMS. The RMS adds these requests into the request queue (Livny & Raman, 1998). Then, the requests are waiting in the queue for the matching service of the RMS for a period of time (called waiting time), see e.g. Abramson et al. (2002). In the matching service, the RMS matches the requests to the shared resources in the grid (Ding et al., 2002) and then builds the connection between the programs and their required resources. Thereafter, the programs can obtain access to the remote resources and exchange information with them through the channels. The grid security mechanism then operates to control the resource access through the Certification, Authorization and Authentication, which constitute various logical connections that causes dynamicity in the network topology. Although the developmental tools and infrastructures for the grid have been widely studied (Foster & Kesselman, 2003), grid reliability analysis and evaluation are not easy because of its complexity, largeness and stiffness. The gird computing contains different types of failures that can make a service unreliable, such as blocking failures, time-out failures, matching failures, network failures, program failures and resource failures. This chapter thoroughly analyzes these failures. Usually the grid performance measure is defined as the task execution time (service time). This index can be significantly improved by using the RMS that divides a task into a set of subtasks which can be executed in parallel by multiple online resources. Many complicated and time-consuming tasks that could not be implemented before are working well under the grid environment now. It is observed in many grid projects that the service time experienced by the users is a random variable. Finding the distribution of this variable is important for evaluating the grid performance and improving the RMS functioning. The service time is affected by many factors. First, various available resources usually have different task processing speeds online. Thus, the task execution time can vary depending on which resource is assigned to execute the task/subtasks. Second, some resources can fail when running the subtasks, so the execution time is also affected by the resource reliability. Similarly, the communication links in grid service can be disconnected during the data transmission. Thus, the communication reliability influences the service time as well as data transmission speed through the communication channels. Moreover, the service requested by a user may be delayed due to the queue of earlier requests submitted from others. Finally, the data dependence imposes constraints on the sequence of the subtasks’ execution, which has significant influence on the service time.
220
Reliability and Performance Models for Grid Computing
Figure 1. Grid computing system
This chapter first introduces the grid computing system and service, and analyzes various failures in grid system. Both reliability and performance are analyzed in accordance with the performability concept. Then the chapter presents models for star- and tree-topology grids respectively. The reliability and performance evaluation tools and algorithms are developed based on the universal generating function, graph theory, and Bayesian approach. Both failure correlation and data dependence are considered in the models.
GRID SERVICE RELIABILITY AND PERFORMANCE Description of the Grid Computing Today, the Grid computing systems are large and complex, such as the IP-Grid (Indiana-Purdue Grid) that is a statewide grid (http://www.ip-grid.org/). IP-Grid is also a part of the TeraGrid that is a nationwide grid in the USA (http://www.teragrid.org/). The largeness and complexity of the grid challenge the existing models and tools to analyze, evaluate, predict and optimize the reliability and performance of grid systems. The global grid system is generally depicted by the Figure 1. Various organizations (Foster et al., 2001), integrate/share their resources on the global grid. Any program running on the grid can use those resources if it can be successfully connected to them and is authorized to access them. The sites that contain the resources or run the programs are linked by the global network as shown in the left part of Figure 1.
221
Reliability and Performance Models for Grid Computing
The distribution of the service tasks/subtasks among the remote resources are controlled by the Resource Management System (RMS) that is the “brain” of the grid computing, see e.g. Livny & Raman (1998). The RMS has five layers in general, as shown in Figure 1: program layer, request layer, management layer, network layer and resource layer. 1.
2.
3.
4.
5.
Program layer: The program layer represents the programs of the customer’s applications. The programs describe their required resources and constraint requirements (such as deadline, budget, function etc). These resource descriptions are translated to the resource requests and sent to the next request layer. Request layer: The request layer provides the abstraction of “program requirements” as a queue of resource requests. The primary goals of this layer are to maintain this queue in a persistent and fault-tolerant manner and to interact with the next management layer by injecting resource requests for matching, claiming matched resources of the requests. Management layer: The management layer may be thought of as the global resource allocation layer. It has the function of automatically detecting new resources, monitoring the resource pool, removing failed/unavailable resources, and most importantly matching the resource requests of a service to the registered/detected resources. If resource requests are matched with the registered resources in the grid, this layer sends the matched tags to the next network layer. Network layer: The network layer dynamically builds connection between the programs and resources when receiving the matched tags and controls them to exchange information through communication channels in a secure way. Resource layer: The resource layer represents the shared resources from different resource providers including the usage policies (such as service charge, reliability, serving time etc.)
Failure Analysis of Grid Service Even though all online nodes or resources are linked through the Internet with one another, not all resources or communication channels are actually used for a specific service. Therefore, according to this observation, we can make tractable models and analyses of grid computing via a virtual structure for a certain service. The grid service is defined as follows: Grid service is a service offered under the grid computing environment, which can be requested by different users through the RMS, which includes a set of subtasks that are allocated to specific resources via the RMS for execution, and which returns the result to the user after the RMS integrates the outputs from different subtasks. The above five layers coordinate together to achieve a grid service. At the “Program layer”, the subtasks (programs) composing the entire grid service task initially send their requests for remote resources to the RMS. The “Request layer” adds these requests in the request queue. Then, the “Management layer” tries to find the sites of the resources that match the requests. After all the requests of those programs in the grid service are matched, the “Network layer” builds the connections among those programs and the matched resources. It is possible to identify various types of failures on respective layers:
222
Reliability and Performance Models for Grid Computing
• •
•
•
•
Program layer: Software failures can occur during the subtask (program) execution; see e.g. Xie (1991) and Pham (2000). Request layer: When the programs’ requests reach the request layer, two types of failures may occur: “blocking failure” and “time-out failure”. Usually, the request queue has a limitation on the maximal number of waiting requests (Livny & Raman, 1998). If the queue is full when a new request arrives, the request blocking failure occurs. The grid service usually has its due time set by customers or service monitors. If the waiting time for the requests in the queue exceeds the due time, the time-out failure occurs, see e.g. Abramson et al. (2002). Management layer: At this layer, “matching failure” may occur if the requests fail to match with the correct resources, see e.g. Xie et al. (2004, pp. 185-186). Errors, such as incorrectly translating the requests, registering a wrong resource, ignoring resource disconnection, misunderstanding the users’ requirements, can cause these matching failures. Network layer: When the subtasks (programs) are executed on remote resources, the communication channels may be disconnected either physically or logically, which causes the “network failure”, especially for those long time transmissions of large dataset, see e.g. Dai et al. (2002). Resource layer: The resources shared on the grid can be of software, hardware or firmware type. The corresponding software, hardware or combined faults can cause resource unavailability.
Grid Service Reliability and Performance Most previous research on distributed computing studied performance and reliability separately. However, performance and reliability are closely related and affect each other, in particular under the grid computing environment. For example, while a task is fully parallelized into m subtasks executed by m resources, the performance is high but the reliability might be low because the failure of any resource prevents the entire task from completion. This causes the RMS to restart the task, which reversely increases its execution time (i.e. reduces performance). Therefore, it is worth to assign some subtasks to several resources to provide execution redundancy. However, excessive redundancy, even though improving the reliability, can decrease the performance by not fully parallelizing the task. Thus, the performance and reliability affect each other and should be considered together in the grid service modeling and analysis. In order to study performance and reliability interactions, one also has to take into account the effect of service performance (execution time) upon the reliability of the grid elements. The conventional models, e.g. Kumar et al. (1986), Chen & Huang (1992), Chen et al. (1997), and Lin et al., (2001), are based on the assumption that the operational probabilities of nodes or links are constant, which ignores the links’ bandwidth, communication time and resource processing time. Such models are not suitable for precisely modeling the grid service performance and reliability. Another important issue that has much influence the performance and reliability is data dependence, that exists when some subtasks use the results from some other subtasks. The service performance and reliability is affected by data dependence because the subtasks cannot be executed totally in parallel. For instance, the resources that are idle in waiting for the input to run the assigned subtasks are usually hotstandby because cold-start is time consuming. As a result, these resources can fail in waiting mode. The considerations presented above lead the following assumptions that lay in the base of grid service reliability and performance model.
223
Reliability and Performance Models for Grid Computing
Assumptions: 1.
2.
3. 4.
5.
6. 7.
8.
9.
The service request reaches the RMS and is being served immediately. The RMS divides the entire service task into a set of subtasks. The data dependence may exist among the subtasks. The order is determined by precedence constraints and is controlled by the RMS. Different grid resources are registered or automatically detected by the RMS. In a grid service, the structure of virtual network (consisting of the RMS and resources involved in performing the service) can form star topology with the RMS in the center or, tree topology with the RMS in the root node. The resources are specialized. Each resource can process one or multiple subtask(s) when it is available. Each resource has a given constant processing speed when it is available and has a given constant failure rate. Each communication channel has constant failure rate and a constant bandwidth (data transmission speed). The failure rates of the communication channels or resources are the same when they are idle or loaded (hot standby model). The failures of different resources and communication links are independent. If the failure of a resource or a communication channel occurs before the end of output data transmission from the resource to the RMS, the subtask fails. Different resources start performing their tasks immediately after they get the input data from the RMS through communication channels. If same subtask is processed by several resources (providing execution redundancy), it is completed when the first result is returned to the RMS. The entire task is completed when all of the subtasks are completed and their results are returned to the RMS from the resources. The data transmission speed in any multi-channel link does not depend on the number of different packages (corresponding to different subtasks) sent in parallel. The data transmission time of each package depends on the amount of data in the package. If the data package is transmitted through several communication links, the link with the lowest bandwidth limits the data transmission speed. The RMS is fully reliable, which can be justified to consider a relatively short interval of running a specific service. The imperfect RMS can also be easily included as a module connected in series to the whole grid service system.
Grid Service Time Distribution and Reliability/Performance Measures The data dependence on task execution can be represented by m×m matrix H such that hki = 1 if subtask i needs for its execution output data from subtask k and hki = 0 otherwise (the subtasks can always be numbered such that k
224
Reliability and Performance Models for Grid Computing
The task execution time is defined as time from the beginning of input data transmission from the RMS to a resource to the end of output data transmission from the resource to the RMS. The amount of data that should be transmitted between the RMS and resource j that executes subtask i is denoted by ai. If data transmission between the RMS and the resource j is accomplished through links belonging to a set γj, the data transmission speed is s j = min(bx )
(1)
Lx g j
Where bx is the bandwidth of the link Lx. Therefore, the random time tij of subtask i execution by resource j can take two possible values tij = tˆij = t j +
ai
(2)
sj
if the resource j and the communication path γj do not fail until the subtask completion and tij = ∞ otherwise. Here, τj is the processing time of the j-th resource. Subtask i can be successfully completed by resource j if this resource and communication path γj do not fail before the end of subtask execution. Given constant failure rates of resource j and links, one can obtain the conditional probability of subtask success as -(l +p )tˆ p j (tˆij ) = e j j ij
(3)
Where πj is the failure rate of the communication path between the RMS and the resource j, which can be calculated as p j = å lx , λx is the failure rate of the link Lx. The exponential distribution (3) is comx g j
mon in software or hardware components’ reliability that had been justified in both theory and practice, see e.g. Xie et al. (2004). These give the conditional distribution of the random subtask execution time tij: Pr(tij = tˆij ) = p j (tij ) and Pr(tij = ¥) = 1 - p j (tij ) . Assume that each subtask i is assigned by the RMS to resources composing set ωi. The RMS can initiate execution of any subtask j (send the data to all the resources from ωi) only after the completion of every subtask k ji . Therefore the random time of the start of subtask i execution Ti can be determined as Ti = max(Tk ) k ji
(4)
Where Tk is random completion time for subtask k. If ji = Æ , i.e. subtask i does not need data produced by any other subtask, the subtask execution starts without delay: Ti = 0. If ji ¹ Æ , Ti can have different realizations Tˆil (1 ≤ l ≤ Ni).Having the time Ti when the execution of subtask i starts and the time tij of
225
Reliability and Performance Models for Grid Computing
subtask i executed by resource j, one obtains the completion time for subtask i on resource j as tij = Ti + tij
(5)
In order to obtain the distribution of random time tij one has to take into account that probability of any realization of tij = Tˆil + tˆij is equal to the product of probabilities of three events: Execution of subtask i starts at time Tˆil : qil=Pr(Ti =Tˆil ); Resource j does not fail before start of execution of subtask i: pj(Tˆil ); Resource j does not fail during the execution of subtask i: pj( tˆij ). Therefore, the conditional distribution of the random time tij given execution of subtask i starts at time Tˆil (Ti=Tˆil ) takes the form Pr( tij = Tˆil + tˆij ) =pj(Tˆil )pj( tˆij ) = pj(Tˆil + tˆij ) = tij = Tˆil + tˆij Tˆil tˆij Tˆil tˆij e -(lj +pj )(Tˆil +tˆij ) ) =pj(Tˆ )pj( tˆij ) = il ˆ ˆ (6) pj(Tˆ + tˆij ) = e -(lj +pj )(Til +tij ) , il
-(l +p )(Tˆ +tˆ ) Pr( tij = ¥ )=1- pj(Tˆil + tˆij )=1- tij = ¥ Tˆil tˆij e -(lj +pj )(Tˆil +tˆij ) )=1- pj(Tˆil + tˆij )=1-e j j il ij .
The random time of subtask i completion Ti is equal to the shortest time when one of the resources from ωi completes the subtask execution: Ti = min(tij ) j wi
(7)
According to the definition of the last subtask m, the time of its beginning corresponds to the service completion time, because the time of the task proceeds with RMS is neglected. Thus, the random service time Θ is equal to Tm. Having the distribution (pmf) of the random value Θ ≡ Tm in the form qml = Pr(Tm = Tˆml ) for 1 ≤ l ≤ Nm, one can evaluate the reliability and performance indices of the grid service. In order to estimate both the service reliability and its performance, different measures can be used depending on the application. In applications where the execution time of each task (service time) is of critical importance, the system reliability R(Θ*) is defined (according to performability concept in Meyer (1980), Grassi et al. (1988) and Tai et al. (1993)) as a probability that the correct output is produced in time less than Θ*. This index can be obtained as Nm
R(Q*) = å qml × 1(Tˆml < Q*) l =1
(8)
When no limitations are imposed on the service time, the service reliability is defined as the probability that it produces correct outputs without respect to the service time, which can be referred to as
226
Reliability and Performance Models for Grid Computing
Figure 2. Grid system with star architecture
R(∞). The conditional expected service time W is considered to be a measure of its performance, which determines the expected service time given that the service does not fail, i.e. Nm
W = å Tˆmlqml / R(¥).
(9)
l =1
STAR TOPOLOGY GRID ARCHITECTURE A grid service is desired to execute a certain task under the control of the RMS. When the RMS receives a service request from a user, the task can be divided into a set of subtasks that are executed in parallel. The RMS assigns those subtasks to available resources for execution. After the resources complete the assigned subtasks, they return the results back to the RMS and then the RMS integrates the received results into entire task output which is requested by the user. The above grid service process can be approximated by a structure with star topology, as depicted by Figure 2, where the RMS is directly connected with any resource through respective communication channels. The star topology is feasible when the resources are totally separated so that their communication channels are independent. Under this assumption the grid service reliability and performance can be derived by using the universal generating function technique.
227
Reliability and Performance Models for Grid Computing
Universal Generating Function The universal generating function (u-function) technique was introduced in (Ushakov, 1987) and proved to be very effective for the reliability evaluation of different types of multi-state systems. The u-function representing the pmf of a discrete random variable Y is defined as a polynomial K
u (z ) = å ak z k , y
(10)
k =1
where the variable Y has K possible values and αk is the probability that Y is equal to yk. To obtain the u-function representing the pmf of a function of two independent random variables φ(Yi, Yj), composition operators are introduced. These operators determine the u-function for φ(Yi, Yj) using simple algebraic operations on the individual u-functions of the variables. All of the composition operators take the form Ki
u j (z ) = å aik z U(z) = ui (z ) Ä f k =1
yik
Kj
Ä å ajh z f
h =1
y jh
Ki
Kj
= å å aik ajh z
f(yik ,y jh )
(11)
k =1 h =1
The u-function U(z) represents all of the possible mutually exclusive combinations of realizations of the variables by relating the probabilities of each combination to the value of function φ(Yi, Yj) for this combination. In the case of grid system, the u-function uij(z) can define pmf of execution time for subtask i assigned to resource j. This u-function takes the form tˆ
uij (z ) = p j (tˆij )z ij + (1 - p j (tˆij ))z ¥
(12)
Where tˆij and p j (tˆij ) are determined according to Eqs. (2) and (3) respectively. The pmf of the random start time Ti for subtask i can be represented by u-function Ui(z) taking the form Li
U i (z ) = å qil z il , Tˆ
(13)
l =1
where qil = Pr(Ti = Tˆil ) . For any realization Tˆil of Ti the conditional distribution of completion time tij for subtask i executed by resource j given Ti = Tˆil according to (6) can be represented by the u-function Tˆ +tˆ uij (z ,Tˆil ) = p j (Tˆil + tˆij )z il ij + (1 - p j (Tˆil + tˆij ))z ¥
228
(14)
Reliability and Performance Models for Grid Computing
Table 1. Parameters of grid system for analytical example No of subtask i
No of resource j
λj+πj (sec-1)
1
1
0.0025
100
0.779
2
0.00018
180
0.968
2
3
tˆij (sec)
p j (tˆij )
3
0.0003
250
-
4
0.0008
300
-
5
0.0005
300
0.861
6
0.0002
430
0.918
The total completion time of subtask i assigned to a pair of resources j and d is equal to the minimum of completion times for these resources according to Eq. (7). To obtain the u-function representing the pmf of this time, given Ti = Tˆil , composition operator with φ(Yj, Yd) = min(Yj, Yd) should be used: ui (z ,Tˆil ) = uij (z ,Tˆil ) Ä uid (z ,Tˆil ) = [ p j (Tˆil + tˆij )z
Tˆil +tˆij
min
Ä[ pd (Tˆil + tˆid )z
Tˆil +tˆid
min
+ (1 - p j (Tˆil + tˆij ))z ¥ ]
+ (1 - pd (Tˆil + tˆid ))z ¥ ]
Tˆ +min(tˆij ,tˆid ) Tˆ +tˆ = p j (Tˆil + tˆij )pd (Tˆil + tˆid )z il + pd (Tˆil + tˆid )(1 - p j (Tˆil + tˆij ))z il id Tˆ +tˆ +p (Tˆ + tˆ )(1 - p (Tˆ + tˆ ))z il ij + (1 - p (Tˆ + tˆ ))(1 - p (Tˆ + tˆ ))z ¥ . j
il
ij
d
il
id
j
il
ij
d
il
id
(15)
The u-function ui (z ,Tˆil ) representing the conditional pmf of completion time Ti for subtask i assigned to all of the resources from set ωi ={j1, …, ji} can be obtained as ui (z ,Tˆil ) = uij (z ,Tˆil ) Ä uij (z ,Tˆil ) Ä ... Ä uij (z ,Tˆil ) . 1
min
2
min
min
i
(16)
ui (z ,Tˆil ) can be obtained recursively: ui (z ,Tˆil ) = uij (z ,Tˆil ), 1
ui (z ,Tˆil ) = ui (z ,Tˆil ) Ä uie (z ,Tˆil ) for e = j2, …, ji. min
(17)
Having the probabilities of the mutually exclusive realizations of start time Ti, qil = Pr(Ti = Tˆil ) and u-functions ui (z ,Tˆil ) representing corresponding conditional distributions of task i completion time, we can now obtain the u-function representing the unconditional pmf of completion time Ti as Ni
Ui (z ) = å qil ui (z ,Tˆil ) .
(18)
l =1
229
Reliability and Performance Models for Grid Computing
Figure 3. Subtask execution precedence constraints for analytical example
Having u-functions Uk (z ) representing pmf of the completion time Tk for any subtask k ji = {k1,..., ki } , one can obtain the u-functions Ui(z) representing pmf of subtask i start time Ti according to (4) as Ni
Tˆ U i (z ) = Uk (z ) Ä Uk (z ) Ä ... Ä Uk (z ) = å qil z il . 1
max
2
max
max
i
l =1
(19)
Ui(z) can be obtained recursively: Ui(z) = z0 U i (z ) = U i (z ) Ä Ue (z ) for e = k1, …, ki. max
(20)
It can be seen that if ji = Æ then Ui(z) = z0. The final u-function Um(z) represents the pmf of random task completion time Tm in the form Nm
U m (z ) = å qml z
Tˆml
.
(21)
l =1
Using the operators defined above one can obtain the service reliability and performance indices by implementing the following algorithm: 1. 2.
230
Determine tˆij for each subtask i and resource j wi using Eq. (2); Define for each subtask i (1 ≤ i ≤ m) Ui (z ) = U i (z ) = z0. For all i: If ji = 0 or if for any k ji Uk (z ) ≠ z0 (u-functions representing the completion times of all of the predecessors of subtask i are obtained)
Reliability and Performance Models for Grid Computing
Ni
2.1. Obtain U i (z ) = å qil z
Tˆil
using recursive procedure (20);
l =1
3. 4.
2.2. For l = 1, …, Ni: 2.2.1. For each j wi obtain uij (z ,Tˆil ) using Eq. (14); 2.2.2. Obtain ui (z ) using recursive procedure (17); 2.3. Obtain Ui (z ) using Eq. (18). If Um(z) = z0 return to step 2. Obtain reliability and performance indices R(Θ*) and W using equations (8) and (9).
Illustrative Example This example presents analytical derivation of the indices R(Θ*) and W for simple grid service that uses six resources. Assume that the RMS divides the service task into three subtasks. The first subtask is assigned to resources 1 and 2, the second subtask is assigned to resources 3 and 4, the third subtask is assigned to resources 5 and 6: ω1 = {1,2}, ω2 = {3,4}, ω3 = {5,6}. The failure rates of the resources and communication channels and subtask execution times are presented in Table 1. Subtasks 1 and 3 get the input data directly from the RMS, subtask 2 needs the output of subtask 1, the service task is completed when the RMS gets the outputs of both subtasks 2 and 3: j1 = j3 = Æ , j2 = {1} , j4 = {2, 3} . These subtask precedence constraints can be represented by the directed graph in Figure 3. Since j1 = j3 = Æ , the only realization of start times T1 and T3 is 0 and therefore, U1(z)=U2(z)=z0 . According to step 2 of the algorithm we can obtain the u-functions representing pmf of completion times t11 , t12 , t35 and t36 . In order to determine the subtask execution time distributions for the individual resources, define the u-functions uij(z) according to Table 1 and Eq. (9): u11 (z , 0) = exp(-0.0025 ´ 100)z 100 + [1 - exp(-0.0025 ´ 100)]z ¥ = 0.779z100 + 0.221z∞. In the similar way we obtain u12 (z , 0) = 0.968z180 + 0.032z∞; u35 (z , 0) = 0.861z300 + 0.139z∞; u35 (z , 0) u36 (z , 0) = 0.861z300 + 0.139z∞; u (z , 0) = 0.918z430 + 36 0.082z∞.
231
Reliability and Performance Models for Grid Computing
Figure 4. A virtual tree structure of a grid service
The u-function representing the pmf of the completion time for subtask 1 executed by both resources 1 and 2 is u12 (z , 0) Ä u11 (z , 0) u12 (z , 0) = (0.779z100 + 0.221z∞)U (z ) = u (z , 0) Ä U1 (z ) = u11 (z , 0) Ä min min min 1 11 Ä u12 (z , 0) = (0.779z100 + 0.221z∞) Ä (0.968z180 + 0.032z∞) min
min
=0.779z100 +0.214z180 + 0.007z∞. The u-function representing the pmf of the completion time for subtask 3 executed by both resources 5 and 6 is u36 (z ) = (0.861z300 + 0.139z∞)U (z ) = u (z , 0) = u (z ) Ä u (z ) Ä U3 (z ) = u3 (z , 0) = u35 (z ) = Ä min 36 3 3 35 min min Ä 300 ∞ 430 ∞ u (z , 0) = u (z ) = Ä u (z ) = (0.861z + 0.139z ) (0.918z + 0.082z ) 3
35
min
36
min
=0.861z300 +0.128z430 + 0.011z∞. Execution of subtask 2 begins immediately after completion of subtask 1. Therefore, U2(z) = U1 (z ) =0.779z100 +0.214z180 + 0.007z∞ (T2 has three realizations 100, 180 and ∞).
232
Reliability and Performance Models for Grid Computing
The u-functions representing the conditional pmf of the completion times for the subtask 2 executed by individual resources are obtained as follows. u23 (z , 100) = e -0.0003´(100+250)z 100+250 + [1 - e -0.0003´(100+250) ]z ¥ =0.9z350+0.1z∞; u23 (z , 180) = e -0.0003´(180+250)z 180+250 + [1 - e -0.0003´(180+250) ]z ¥ =0.879z430+0.121z∞; u23 (z , ¥) = z ¥ ; u24 (z , 100) = e -0.0008´(100+300)z 100+300 + [1 - e -0.0008´(100+300) ]z ¥ =0.726z400+0.274z∞; u24 (z , 180) = e -0.0008´(180+300)z 180+300 + [1 - e -0.0008´(180+300) ]z ¥ =0.681z480+0.319z∞; u24 (z , ¥) = z ¥ . The u-functions representing the conditional pmf of subtask 2 completion time are: u2 (z , 100) = u23 (z , 100) Ä u24 (z, 100) = (0.9z350+0.1z∞) u2 (z , 100) = u23 (z , 100) Ä u24 (z, 100) = Ä min min min (0.9z350+0.1z∞) Ä (0.726z400+0.274z∞) min
=0.9z350+0.073z400+0.027z∞; u2 (z , 180) = u23 (z , 180) Ä u24 (z, 180) = (0.879z430+0.121z∞) u2 (z , 180) = u23 (z , 180) Ä u24 (z, 180) = Ä min min min (0.879z430+0.121z∞) Ä (0.681z480+0.319z∞) min
=0.879z430+0.082z480+0.039z∞; u2 (z , ¥) = u23 (z , ¥) Ä u24 (z , ¥) = z ¥ . min
According to Eq. (18) the unconditional pmf of subtask 2 completion time is represented by the following u-function U2 (z ) = 0.779u2 (z , 100) + 0.214u2 (z , 180) + 0.007z ¥ =0.779(0.9z350+0.073z400+0.027z∞)+0.214(0.879z430+0.082z480+0.039z∞)+0.007z∞ =0.701z350+0.056z400+0.188z430+0.018z480+0.037z∞ The service task is completed when subtasks 2 and 3 return their outputs to the RMS (which corresponds to the beginning of subtask 4). Therefore, the u-function representing the pmf of the entire service time is obtained as U 4 (z ) = U2 (z ) Ä U3 (z ) max
233
Reliability and Performance Models for Grid Computing
=(0.701z350+0.056z400+0.188z430+0.018z480+0.037z∞) Ä (0.861z300 +0.128z430 + 0.011z∞)=0.603z350 max +0.049z400 +0.283z430 +0.017z480 +0.048z∞. The pmf of the service time is: Pr(T4 = 350) = 0.603; Pr(T4 = 400) = 0.049; Pr(T4 = 430) = 0.283; Pr(T4 = 480) = 0.017; Pr(T4 = ∞) = 0.048. From the obtained pmf we can calculate the service reliability using Eq. (8): R(Θ*) = 0.603 for 350< Θ* ≤ 400; R(Θ*) = 0.652 for 400< Θ* ≤430; R(Θ*) = 0.935 for 430< Θ* ≤ 480; R(∞) = 0.952 and the conditional expected service time according to Eq. (9): W = (0.603×350 + 0.049×400 + 0.283×430 + 0.017×480) / 0.952 = 378.69 sec.
TREE TOPOLOGY GRID ARCHITECTURE In the star grid, the RMS is connected with each resource by one direct communication channel (link). However, such approximation is not accurate enough even though it simplifies the analysis and computation. For example, several resources located in a same local area network (LAN) can use the same gateway to communicate outside the network. Therefore, all these resources are not connected with the RMS through independent links. The resources are connected to the gateway, which communicates with the RMS through one common communication channel. Another example is a server that contains several resources (has several processors that can run different applications simultaneously, or contains different databases). Such a server communicates with the RMS through the same links. These situations cannot be modeled using only the star topology grid architecture. In this section, we present a more reasonable virtual structure which has a tree topology. The root of the tree virtual structure is the RMS, and the leaves are resources, while the branches of the tree represent the communication channels linking the leaves and the root. Some channels are commonly used by multiple resources. An example of the tree topology is given in Figure 3 in which four resources (R1, R2, R3, R4) are available for a service. The tree structure models the common cause failures in shared communication channels. For example, in Figure 4, the failure in channel L6 makes resources R1, R2, and R3 unavailable. This type of common cause failure was ignored by the conventional parallel computing models, and the above star-topology models. For small-area communication, such as a LAN or a cluster, such assumption that ignores the common cause failures on communications is acceptable because the communication time is negligible compared to the processing time. However, for wide-area communication, such as the grid system, it is more likely to have failure on communication channels. Therefore, the communication time cannot be neglected. In many cases, the communication time may dominate the processing time due to the large amount of data transmitted. Therefore, the virtual tree structure is an adequate model representing the functioning of grid services.
234
Reliability and Performance Models for Grid Computing
Table 2. Parameters of the MTSTs’ paths Elements, subtasks
R1, J1
R2, J2
R3, J2
R4, J1
Data transmission speed (Kbps)
5
6
4
10
Data transmission time (s)
30
15
22.5
15
Processing time (s)
48
25
35.5
38
Time to subtask completion (s)
78
40
58
53
Algorithms for Determining the pmf of the Task Execution Time With the tree-structure, the simple u-function technique is not applicable because it does not consider the failure correlations. Thus, new algorithms are required. This section presents a novel algorithm to evaluate the performance and reliability for the tree-structured grid service based on the graph theory and the Bayesian approach.
Minimal Task Spanning Tree (MTST) The set of all nodes and links involved in performing a given task form a task spanning tree. This task spanning tree can be considered to be a combination of minimal task spanning trees (MTST), where each MTST represents a minimal possible combination of available elements (resources and links) that guarantees the successful completion of the entire task. The failure of any element in a MTST leads to the entire task failure. For solving the graph traversal problem, several classical algorithms have been suggested, such as Depth-First search, Breadth-First search, etc. These algorithms can find all MTST in an arbitrary graph (Dai et al., 2002). However, MTST in graphs with a tree topology can be found in a much simpler way because each resource has a single path to the RMS, and the tree structure is acyclic. After the subtasks have been assigned to corresponding resources, it is easy to find all combinations of resources such that each combination contains exactly m resources executing m different subtasks that compose the entire task. Each combination determines exactly one MTST consisting of links that belong to paths from the m resources to the RMS. The total number of MTST is equal to the total number of such combinations N, where m
N = Õ| wj |
(22)
j =1
(see Example 4.2.1). Along with the procedures of searching all the MTST, one has to determine the corresponding running time and communication time for all the resources and links. For any subtask j, and any resource k assigned to execute this subtask, one has the amount of input and output data, the bandwidths of links, belonging to the corresponding paths γk, and the resource processing time. With these data, one can obtain the time of subtask completion (see Example 4.2.2).
235
Reliability and Performance Models for Grid Computing
Some elements of the same MTST can belong to several paths if they are involved in data transmission to several resources. To track the element involvement in performing different subtasks and to record the corresponding times in which the element failure causes the failure of a subtask, we create the lists of two-field records for each subtask in each MTST. For any MTST Si (1 ≤ i ≤ N), and any subtask j (1 ≤ j ≤ m), this list contains the names of the elements involved in performing the subtask j, and the corresponding time of subtask completion yij (see Example 4.2.3). Note that yij is the conditional time of subtask j completion given only MTST i is available. Note that a MTST completes the entire task if all of its elements do not fail by the maximal time needed to complete subtasks in performing which they are involved. Therefore, when calculating the element reliability in a given MTST, one has to use the corresponding record with maximal time.
pmf of The Task Execution Time Having the MTST, and the times of their elements involvement in performing different subtasks, one can determine the pmf of the entire service time. First, we can obtain the conditional time of the entire task completion given only MTST Si is available as Y{i } = max(yij ) for any 1 ≤ i ≤ N: 1£ j £m
(23)
For a set ψ of available MTST, the task completion time is equal to the minimal task completion times among the MTST. ù é Yy = min(Y{i } ) = min ê max(yij )ú . i y i y ë1£ j £m û
(24)
Now, we can sort the MTST in an increasing order of their conditional task completion times Y{i}, and divide them into different groups containing MTST with identical conditional completion time. Suppose there are K such groups denoted by G1, G2,…,GK where 1 ≤ K ≤ N, and any group Gi contains MTST with identical conditional task completion times Θi (0 ≤ Θ1 < Θ2<…< ΘK). Then, it can be seen that the probability Qi = Pr(Θ = Θi) can be obtained as Qi = Pr (Ei ,Ei -1 ,Ei -2 ,...,E1 )
(25)
Where Ei is the event when at least one of MTST from the group Gi is available, and Ei is the event when none of MTST from the group Gi is available. Suppose the MTST in a group Gi are arbitrarily ordered, and Fij (j=1,2,…, Ni) represents an event when the j-th MTST in the group is available. Then, the event Ei can be expressed by Ni
Ei = Fij , j =1
236
(26)
Reliability and Performance Models for Grid Computing
and (25) takes the form Ni
Pr(Ei , Ei -1, Ei -2 ,..., E1 ) = Pr(Ei , Ei -1, Ei -2 ,..., E1 ) Pr( Fij , Ei -1, Ei -2 ,..., E1 ) = Ni
j =1
Pr( Fij , Ei -1, Ei -2 ,..., E1 ) .
(27)
j =1
Using the Bayesian theorem on conditional probability, we obtain from (27) that Ni
(
)
Qi = å Pr (Fij ) × Pr Fi ( j -1), Fi ( j -2),..., Fi 1, E1, E 2 , , Ei -1 Fij . j =1
(28)
The probability Pr(Fij) can be calculated as a product of the reliabilities of all the elements belonging to the j-th MTST from group Gi.
(
)
The probability Pr Fi ( j -1), Fi ( j -2),..., Fi 1, E1, E 2 , , Ei -1 Fij can be computed by the following twostep algorithm (see Example 4.2.4). Step 1: Identify failures of all the critical elements’ in a period of time (defined by the start and end time), during which they lead to the failures of any MTST from groups Gm for m=1,2,…i-1 (events E m ), and any MTST Sk from group Gi for k = 1,2,…, j−1 (events F ik ), but do not affect the MTST Sj from group Gi. Step 2: Generate all the possible combinations of the identified critical elements that lead to the event Fi ( j -1), Fi ( j -2),..., Fi 1, E1, E 2 , , Ei -1 Fij using a binary search, and compute the probabilities of those combinations. The sum of the probabilities obtained is equal to
(
)
Pr Fi ( j -1), Fi ( j -2),..., Fi 1, E1, E 2 , , Ei -1 Fij . When calculating the failure probabilities of MTSTs’ elements, the maximal time from the corresponding records in a list for the given MTST should ___ ___
be used. The algorithm for obtaining the probabilities Pr{ E1 , E 2 , Ei -1 Ei } can be found in Dai et al. (2002). Having the conditional task completion times Y{i}for different MTST, and the corresponding probabilities Qi, one obtains the task completion time distribution (Θi, Qi), 1 ≤ i ≤ K, and can easily calculate the indices (8) & (9) (see Example 4.2.5).
Illustrative Example Consider the virtual grid presented in Figure 3, and assume that the service task is divided into two subtasks J1 assigned to resources R1 & R4, and J2 assigned to resources R2 & R3. J1, and J2 require 50Kbits, and 30Kbits of input data, respectively, to be sent from the RMS to the corresponding resource; and 100Kbits, and 60Kbits of output data respectively to be sent from the resource back to the RMS. The subtask processing times for resources, bandwidth of links, and failure rates are presented in Fig. 3 next to the corresponding elements.
237
Reliability and Performance Models for Grid Computing
Table 3. pmf of service time Θi
Qi
Θi Qi
53
0.3738
19.8114
58
0.1480
8.584
78
0.0945
7.371
∞
0.3837
∞
The Service MTST The entire graph constitutes the task spanning tree. There exist four possible combinations of two resources executing both subtasks: {R1, R2}, {R1, R3}, {R4, R2}, {R4, R3}. The four MTST corresponding to these combinations are: S1: {R1, R2, L1, L2, L5, L6}; S2: {R1, R3, L1, L3, L5, L6}; S3: {R2, R4, L2, L5, L4, L6}; S4: {R3, R4, L3, L4, L6}.
Parameters of MTSTs’ Paths Having the MTST, one can obtain the data transmission speed for each path between the resource, and the RMS (as minimal bandwidth of links belonging to the path); and calculate the data transmission times, and the times of subtasks’ completion. These parameters are presented in Table 2. For example, resource R1 (belonging to two MTST S1 & S2) processes subtask J1 in 48 seconds. To complete the subtask, it should receive 50Kbits, and return to the RMS 100Kbits of data. The speed of data transmission between the RMS and R1 is limited by the bandwidth of link L1, and is equal to 5 Kbps. Therefore, the data transmission time is 150/5=30 seconds, and the total time of task completion by R1 is 30+48=78 seconds.
List of MTST Elements Now one can obtain the lists of two-field records for components of the MTST. S1: path for J1:(R1,78); (L1,78); (L5,78); (L6,78); path for J2: (R2,40); (L2,40); (L5,40); (L6,40). S2: path for J1: (R1,78), (L1,78), (L5,78), (L6,78); path for J2: (R3,58), (L3,58), (L6,58). S3: path for J1: (R4,53), (L4,53); path for J2: (R2,40), (L2,40), (L5,40), (L6,40). S4: path for J1: (R4,53), (L4,53); path for J2: (R3,58), (L3,58), (L6,58).
pmf of Task Completion Time The conditional times of the entire task completion by different MTST are Y1=78; Y2=78; Y3=53; Y4=58.
238
Reliability and Performance Models for Grid Computing
Therefore, the MTST compose three groups: G1 = {S3} with Θ1 = 53; G2 = {S4} with Θ2= 58; and G3 = {S1, S2} with Θ3 = 78. According to (25), we have for group G1: Q1=Pr(E1)=Pr(S3). The probability that the MTST S3 completes the entire task is equal to the product of the probabilities that R4, and L4 do not fail by 53 seconds; and R2, L2, L5, and L6 do not fail by 40 seconds. Pr(Θ=53)=Q1=exp(−0.004×53)exp(−0.004×53)exp(−0.008×40) ×exp(−0.003×40)exp(−0.001×40)exp(−0.002×40) = 0.3738. Now we can calculate Q2 as
(
)
(
)
(
Q2 = Pr(E 2 , E1 ) = Pr (F21 ) Pr E1 F21 = Pr (F21 ) Pr F11 F21 = Pr(E 2 , E1 ) Pr (F21 ) Pr E1 F21
( (
)
(
)
(
)
(
)
)
Pr (F21 ) Pr F11 F21 Pr (S 4 ) Pr S 3 S 4 = Pr (F21 ) Pr E1 F21 = Pr (F21 ) Pr F11 F21 = Pr (S 4 ) Pr S 3 S 4
)
because G2, and G1 have only one MTST each. The probability that the MTST S4 completes the entire task Pr(S4) is equal to the product of probabilities that R3, L3, and L6 do not fail by 58 seconds; and R4, and L4 do not fail by 53 seconds. Pr(S4) = exp(-0.004 ´ 53) exp(-0.003 ´ 58) exp(-0.004 ´ 53) exp(-0.004 ´ 58) exp(-0.002 ´ 58) = 0.3883
(
)
To obtain Pr S 3 S 4 , one first should identify the critical elements according to the algorithm presented in the Dai et al. (2002). These elements are R2, L2, and L5. Any failure occurring in one of these elements by 40 seconds causes failure of S3, but does not affect S4. The probability that at least one failure occurs in the set of critical elements is
(
)
(
)
Pr S 3 S 4 = Pr S 3 S 4 1 - exp(-0.008 ´ 40) exp(-0.003 ´ 40) exp(-0.001 ´ 40) = 1 - exp(-0.008 ´ 40) exp(-0.003 ´ 40) exp(-0.001 ´ 40) = 0.3812.
Then,
(
)
(
)
Pr(Θ =58) = Pr(E 2 , E1 ) =Pr(S4) Pr S 3 S 4 = Pr(E 2 , E1 ) Pr S 3 S 4 0.3883 ´ 0.3812 =Pr(S4) Pr S 3 S 4 = 0.3883 ´ 0.3812 =0.1480.
(
)
239
Reliability and Performance Models for Grid Computing
Now one can calculate Q3 for the last group G3 = {S1, S2} corresponding to Θ3 = 78 as
(
)
(
)
Q3 = Pr(E 3 , E 2 , E1 ) = Pr(E 3 , E 2 , E1 ) Pr (F31 ) Pr E1, E 2 F31 + Pr (F32 ) Pr F31, E1, E 2 F32 = Pr (F31 ) Pr E1, E 2 F31 + Pr (F32 ) Pr F31, E1, E 2 F32
(
)
(
)
(
(
= Pr (S1 ) Pr S 3 , S 4 S1 + Pr (S 2 ) Pr S1, S 3 , S 4 S 2
)
)
The probability that the MTST S1 completes the entire task is equal to the product of the probabilities that R1, L1, L5, and L6 do not fail by 78 seconds; and R2, and L2 do not fail by 40 seconds. Pr (S1 ) = exp(-0.007 ´ 78) exp(-0.008 ´ 40) exp(-0.005 ´ 78) exp(-0.003 ´ 40) ´ exp(-0.001 ´ 78) exp(-0.002 ´ 78) = 0.1999. The probability that the MTST S2 completes the entire task is equal to the product of the probabilities that R1, L1, L5, and L6 do not fail by 78 seconds; and R3, and L3 do not fail by 58 seconds. Pr (S 2 ) = exp(-0.007 ´ 78) exp(-0.003 ´ 58) exp(-0.005 ´ 78) exp(-0.004 ´ 58) ´ exp(-0.001 ´ 78) exp(-0.002 ´ 78) = 0.2068.
(
)
To obtain Pr S , S S , one first should identify the critical elements. Any failure of either R4 or 3 4 1 L4 in the time interval from 0 to 53 seconds causes failures of both S3, and S4; but does not affect S1. Therefore,
(
)
(
)
Pr S 3 , S 4 S1 = Pr S 3 , S 4 S1 1 - exp(-0.004 ´ 53) exp(-0.004 ´ 53) = 1 - exp(-0.004 ´ 53) exp(-0.004 ´ 53) =0.3456.
(
)
The critical elements for calculating Pr S1, S 3 , S 4 S 2 are R2, and L2 in the interval from 0 to 40 seconds; and R4, and L4 in the interval from 0 to 53 seconds. The failure of both elements in any one of the following four combinations causes failures of S3, S4, and S1, but does not affect S2: 1. 2. 3. 4.
R2 during the first 40 seconds, and R4 during the first 53 seconds; R2 during the first 40 seconds, and L4 during the first 53 seconds; L2 during the first 40 seconds, and R4 during the first 53 seconds; and L2 during the first 40 seconds, and L4 during the first 53 seconds. Therefore,
4 é 2 ù Pr S1, S 3 , S 4 S 2 = Pr S1, S 3 , S 4 S 2 1 - Õ êê1 - Õ [1 - exp(lij × tij )]úú = i =1 ë j =1 û 4 é 2 ù 1 - Õ êê1 - Õ [1 - exp(lij × tij )]úú =0.1230, i =1 ë j =1 û
(
240
)
(
)
Reliability and Performance Models for Grid Computing
where λij is the failure rate of the j-th critical element in the i-th combination (j=1,2), (i=1,2,3,4); and tij is the duration of the time interval for the corresponding critical element. Pr (S1 ), Pr (S 2 ), Pr S 3 , S 4 S1 Pr S1, S 3 , S 4 S 2 , and , one can calculate Having the values of
(
)
(
)
Pr(Θ =78)= Q3 = 0.1999 × 0.3456 + 0.2068 × 0.1230 = 0.0945. After obtaining Q1, Q2, and Q3, one can evaluate the total task failure probability as Pr(Θ = ∞) = 1− Q1 − Q2 − Q3 = 1 − 0.3738 − 0.1480 − 0.0945 = 0.3837,
and obtain the pmf of service time presented in Table 3.
4.2.5. Calculating the Reliability Indices From Table 3, weone obtains the probability that the service does not fail as R(∞) = Q1 + Q2 + Q3 = 0.6164, the probability that the service time is not greater than a pre-specified value of θ* = 60 seconds as 3
R(q*) = å Qi × 1( i < q*) = 0.3738 + 0.1480 = 0.5218 , i =1
and the expected service execution time given that the system does not fail as 3
W = å iQi / R(¥) = 35.7664 / 0.6164 = 58.025 seconds. i =1
Parameterization and Monitoring In order to obtain the reliability and performance indices of the grid service one has to know such model parameters as the failure rates of the virtual links and the virtual nodes, and bandwidth of the links. It is easy to estimate those parameters by implementing the monitoring technology. A monitoring system (called Alertmon Network Monitor,http://www.abilene.iu.edu/noc.html) is being applied in the IP-grid (Indiana Purdue Grid) project (www.ip-grid.org), to detect the component failures, to record service behavior, to monitor the network traffics and to control the system configurations. With this monitoring system, one can easily obtain the parameters required by the grid service reliability model by adding the following functions in the monitoring system:
241
Reliability and Performance Models for Grid Computing
1.
2.
Monitoring the failures of the components (virtual links and nodes) in the grid service, and recording the total execution time of those components. The failure rates of the components can be simply estimated by the number of failures over the total execution time. Monitoring the real time network traffic of the involved channels (virtual links) in order to obtain the bandwidth of the links.
To realize the above monitoring functions, network sensors are required. We presented a type of sensors attaching to the components, acting as neurons attaching to the skins. It means the components themselves or adjacent components play the roles of sensors at the same time when they are working. Only a little computational resource in the components is used for accumulating failures/time and for dividing operations, and only a little memory is required for saving the data (accumulated number of failures, accumulated time and current bandwidth). The virtual nodes that have memory and computational function can play the sensing role themselves; if some links have no CPU or memory then the adjacent processors or routers can perform this data collecting operations. Using such self-sensing technique avoids overloading of the monitoring center even in the grid system containing numerous components. Again, it does not affects the service performance considerably since only small part of computation and storage resources is used for the monitoring. In addition, such self-sensing technique can also be applied in monitoring other measures. When evaluating the grid service reliability, the RMS automatically loads the required parameters from corresponding sensors and calculates the service reliability and performance according to the approaches presented in the previous sections. This strategy can also be used for implementing the Autonomic Computing concept.
CONCLUSION Grid computing is a newly developed technology for complex systems with large-scale resource sharing, wide-area communication, and multi-institutional collaboration. Although the developmental tools and techniques for the grid have been widely studied, grid reliability analysis and modeling are not easy because of their complexity of combining various failures. This chapter introduced the grid computing technology and analyzed the grid service reliability and performance under the context of performability. The chapter then presented models for star-topology grid with data dependence and tree-structure grid with failure correlation. Evaluation tools and algorithms were presented based on the universal generating function, graph theory, and Bayesian approach. Numerical examples are presented to illustrate the grid modeling and reliability/performance evaluation procedures and approaches. Future research can extend the models for grid computing to other large-scale distributed computing systems. After analyzing the details and specificity of corresponding systems, the approaches and models can be adapted to real conditions. The models are also applicable to wireless network that is more failure prone. Hierarchical models can also be analyzed in which output of lower level models can be considered as the input of the higher level models. Each level can make use of the proposed models and evaluation tools.
242
Reliability and Performance Models for Grid Computing
ACKNOWLEDGMENT This work was supported in part by National Science Foundation (NSF) under grant number 0831609.
REFERENCES Abramson, D., Buyya, R., & Giddy, J. (2002). A computational economy for grid computing and its implementation in the Nimrod-G resource broker. Future Generation Computer Systems, 18(8), 1061–1074. doi:10.1016/S0167-739X(02)00085-7 Berman, F., Wolski, R., Casanova, H., Cirne, W., Dail, H., & Faerman, M. (2003). Adaptive computing on the Grid using AppLeS. IEEE Transactions on Parallel and Distributed Systems, 14(4), 369–382. doi:10.1109/TPDS.2003.1195409 Cao, J., Jarvis, S. A., Saini, S., Kerbyson, D. J., & Nudd, G. R. (2002). ARMS: An agent-based resource management system for grid computing. Science Progress, 10(2), 135–148. Chen, D. J., Chen, R. S., & Huang, T. H. (1997). A heuristic approach to generating file spanning trees for reliability analysis of distributed computing systems. Computers and Mathematics with Applications, 34(10), 115–131. doi:10.1016/S0898-1221(97)00210-1 Chen, D. J., & Huang, T. H. (1992). Reliability analysis of distributed systems based on a fast reliability algorithm. IEEE Transactions on Parallel and Distributed Systems, 3(2), 139–154. doi:10.1109/71.127256 Dai, Y. S., & Levitin, G. (2006). Reliability and performance of tree-structured grid services . IEEE Transactions on Reliability, 55(2), 337–349. doi:10.1109/TR.2006.874940 Dai, Y. S., Pan, Y., & Zou, X. K. (2006). A hierarchical modelling and analysis for grid service reliability. IEEE Transactions on Computers. Dai, Y. S., Xie, M., & Poh, K. L. (2002), Reliability analysis of grid computing systems. IEEE Pacific Rim International Symposium on Dependable Computing (PRDC2002), (pp. 97-104). New York: IEEE Computer Press. Dai, Y. S., Xie, M., & Poh, K. L. (2005). Markov renewal models for correlated software failures of multiple types. IEEE Transactions on Reliability, 54(1), 100–106. doi:10.1109/TR.2004.841709 Dai, Y. S., Xie, M., & Poh, K. L. (2006).Availability modeling and cost optimization for the grid resource management system. IEEE Transactions on Systems, Man, and Cybernetics. Part A . Systems and Humans: a Publication of the IEEE Systems, Man, and Cybernetics Society., 38(1), 170. Dai, Y. S., Xie, M., Poh, K. L., & Liu, G. Q. (2003). A study of service reliability and availability for distributed systems. Reliability Engineering & System Safety, 79(1), 103–112. doi:10.1016/S09518320(02)00200-4
243
Reliability and Performance Models for Grid Computing
Dai, Y. S., Xie, M., Poh, K. L., & Ng, S. H. (2004). A model for correlated failures in N-version programming. IIE Transactions, 36(12), 1183–1192. doi:10.1080/07408170490507729 Das, S. K., Harvey, D. J., & Biswas, R. (2001). Parallel processing of adaptive meshes with load balancing. IEEE Transactions on Parallel and Distributed Systems, 12(12), 1269–1280. doi:10.1109/71.970562 Ding, Q., Chen, G. L., & Gu, J. (2002). A unified resource mapping strategy in computational grid environments. Journal of Software, 13(7), 1303–1308. Foster, I., & Kesselman, C. (2003). The Grid 2: Blueprint for a new computing infrastructure. San Francisco: Morgan-Kaufmann. Foster, I., Kesselman, C., Nick, J. M., & Tuecke, S. (2002). Grid services for distributed system integration. Computer, 35(6), 37–46. doi:10.1109/MC.2002.1009167 Foster, I., Kesselman, C., & Tuecke, S. (2001). The anatomy of the grid: Enabling scalable virtual organizations. International Journal of High Performance Computing Applications, 15, 200–222. doi:10.1177/109434200101500302 Grassi, V., Donatiello, L., & Iazeolla, G. (1988). Performability evaluation of multicomponent fault tolerant systems. IEEE Transactions on Reliability, 37(2), 216–222. doi:10.1109/24.3744 Krauter, K., Buyya, R., & Maheswaran, M. (2002). A taxonomy and survey of grid resource management systems for distributed computing. Software, Practice & Experience, 32(2), 135–164. doi:10.1002/ spe.432 Kumar, A. (2000). An efficient SuperGrid protocol for high availability and load balancing. IEEE Transactions on Computers, 49(10), 1126–1133. doi:10.1109/12.888048 Kumar, V. K. P., Hariri, S., & Raghavendra, C. S. (1986). Distributed program reliability analysis. IEEE Transactions on Software Engineering, SE-12, 42–50. Levitin, G., Dai, Y. S., & Ben-Haim, H. (2006). Reliability and performance of star topology grid service with precedence constraints on subtask execution. IEEE Transactions on Reliability, 55(3), 507–515. doi:10.1109/TR.2006.879651 Levitin, G., Dai, Y. S., Xie, M., & Poh, K. L. (2003). Optimizing survivability of multi-state systems with multi-level protection by multi-processor genetic algorithm. Reliability Engineering & System Safety, 82, 93–104. doi:10.1016/S0951-8320(03)00136-4 Lin, M. S., Chang, M. S., Chen, D. J., & Ku, K. L. (2001). The distributed program reliability analysis on ring-type topologies. Computers & Operations Research, 28, 625–635. doi:10.1016/S03050548(99)00151-3 Liu, G. Q., Xie, M., Dai, Y. S., & Poh, K. L. (2004). On program and file assignment for distributed systems. Computer Systems Science and Engineering, 19(1), 39–48. Livny, M., & Raman, R. (1998). High-throughput resource management. In The Grid: Blueprint for a new computing infrastructure (pp. 311-338). San Francisco: Morgan-Kaufmann
244
Reliability and Performance Models for Grid Computing
Meyer, J. (1980). On evaluating the performability of degradable computing systems. IEEE Transactions on Computers, 29, 720–731. doi:10.1109/TC.1980.1675654 Nabrzyski, J., Schopf, J. M., & Weglarz, J. (2003). Grid Resource Management. Amsterdam: Kluwer Publishing. Pham, H. (2000). Software reliability. Singapore: Springer-Verlag. Tai, A., Meyer, J., & Avizienis, A. (1993). Performability enhancement of fault-tolerant software. IEEE Transactions on Reliability, 42(2), 227–237. doi:10.1109/24.229492 Xie, M. (1991). Software reliability modeling. Hackensack, NJ: World Scientific Publishing Company. Xie, M., Dai, Y. S., & Poh, K. L. (2004). Computing systems reliability: Models and analysis. New York: Kluwer Academic Publishers. Yang, B., & Xie, M. (2000). A study of operational and testing reliability in software reliability analysis. Reliability Engineering & System Safety, 70, 323–329. doi:10.1016/S0951-8320(00)00069-7
KEY TERMS AND DEFINITIONS Bayesian Analysis: Use Bayes method to get the posterior distribution from a prior distribution. Graph Theory: Use graph algorithms to analyze given a network graph. Grid Computing: Grid computing is a newly developed technology for complex systems with largescale resource sharing, wide-area communication, and multi-institutional collaboration. Modeling: A representation, generally in mathematical presentations, to show the construction or appearance of a computing system. Performance: The inverse of the execution time. Reliability: The probability for the service to be successfully completed given a execution time. Universal Generating Function: Also called as u-function that is a technique to express and evaluate models in a polynomial format.
245
246
Chapter 11
Mixed Programming Models Using Parallel Tasks Jörg Dümmler Chemnitz University of Technology, Germany Thomas Rauber University Bayreuth, Germany Gudula Rünger Chemnitz University of Technology, Germany
ABSTRACT Parallel programming models using parallel tasks have shown to be successful for increasing scalability on medium-size homogeneous parallel systems. Several investigations have shown that these programming models can be extended to hierarchical and heterogeneous systems which will dominate in the future. In this chapter, the authors discuss parallel programming models with parallel tasks and describe these programming models in the context of other approaches for mixed task and data parallelism. They discuss compiler-based as well as library-based approaches for task programming and present extensions to the model which allow a flexible combination of parallel tasks and an optimization of the resulting communication structure.
INTRODUCTION Large modular parallel applications can be decomposed into a set of cooperating parallel tasks. This set of parallel tasks and their cooperation or coordination structure are a flexible representation of a parallel program for the specific application. The flexibility in scheduling and mapping the parallel tasks can be exploited to achieve efficiency and scalability on a specific distributed memory platform by choosing a suitable mapping and scheduling of the tasks. Each parallel task is responsible for the computation of a specific part or module of the application, and can be executed on an arbitrary number of processors. The terms multiprocessor tasks, malleable tasks and moldable tasks have been used to denote such parallel tasks. In the following, we use the term multiprocessor task (M-task). An M-task can be implemented DOI: 10.4018/978-1-60566-661-7.ch011
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Mixed Programming Models Using Parallel Tasks
using an SPMD programming model (basic M-task) or can be hierarchically composed of other M-tasks and thereby support nested parallelism (composed M-task). The advantage of the M-task programming model is to exploit coarse-grained parallelism between M-tasks and fine-grained parallelism within basic M-tasks in the same program and thus the potential parallelism and scalability can be increased. Each M-task provides an interface consisting of a set of input and output parameters. These parameters are parallel data structures that are distributed among the processors executing the M-task according to a predefined distribution scheme, e.g. a block-wise distribution of an array. A data dependence between M-tasks M1 and M2 arises if M1 produces output data required as an input for M2. Such data dependencies might lead to data re-distribution operations if M1 and M2 are executed on different sets of processors or if M1 produces its output in a different data distribution than expected by M2. Control dependencies are introduced by coordination operators, e.g. loop constructs for the repeated execution of an M-task or constructs for the conditional execution of an M-task. The data and control dependencies between M-tasks can be captured by a graph representation. Examples are macro dataflow graphs(Ramaswamy, Sapatnekar, & Banerjee, 1997) or series-parallel (SP) graphs(Rauber & Rünger, 2000). The actual execution of an M-task program is based on a schedule of the M-tasks that has to take the data and control dependencies into account. M-tasks that are connected by a data or control dependence have to be executed subsequently. For independent M-tasks both, a concurrent execution on disjoint processor groups or an execution one after another are possible. The optimal schedule depends on the structure of the application and on the communication and computing performance of the parallel target platform. For the same application a pure data parallel schedule that executes all M-tasks consecutively on all available processors might lead to the best results on one platform but a mixed task and data parallel schedule may result in lower execution times on another platform. Thus, the parallel programming with M-tasks offers a very flexible programming style exploiting different levels of granularity and making parallel programs easily adoptable to a specific parallel platform. Examples for M-task applications come from multiple areas. Large multi-disciplinary simulation programs consist of a collection of algorithms from different fields, e.g. aircraft design (Chapman, Haines, Mehrota, Zima, & van Rosendale, 1997; Bal & Haines, 1998) that uses models from aerodynamics, propulsion, and structural analysis or environmental simulations (Chapman et al., 1997) that combine atmospheric, surface water, and ground water models. Examples from numerical analysis include solution methods for ordinary differential equations (ODEs) like extrapolation methods (Rauber & Rünger, 2000), iterated Runge-Kutta methods (Rauber & Rünger, 1999a), implicitly iterated Runge-Kutta methods (Rauber & Rünger, 2000), or Parallel Adams methods (Rauber & Rünger, 2007). These time-stepping methods compute a fixed number of independent stage vectors within each time step and combine these vectors into the new approximation vector for the next time step. Partial differential equations (PDEs) can be defined over geometrically complex domains that are decomposed into sets of partially overlapping discretization meshes. Solution methods for PDEs can exploit coarse-grained parallelism between these meshes and fine-grained parallelism within the meshes (Merlin, Baden, Fink, & Chapman, 1999; Diaz, Rubio, Soler, & Troya, 2003). Hierarchical algorithms and divide-and-conquer algorithms compute partial solutions for independent subsets of the input and derive the final solution from these partial results. Examples are multi-level matrix multiplication algorithms (Hunold, Rauber, & Rünger, 2008). Stream-based applications process input streams by several pipeline stages and can exploit task and data parallelism by replicating non-scaling stages and executing the replicas concurrently. Examples come from image processing (Subhlok & Yang, 1997) and sensor-based programs that periodically process data produced by sensors (Subhlok & Yang, 1997; Bal & Haines, 1998; Orlando, Palmerini, & Perego, 2000).
247
Mixed Programming Models Using Parallel Tasks
There is a large variety of specific parallel programming models which support the programming with parallel tasks, multiprocessor tasks or related concepts. In the next section we start with an overview of programming approaches for mixed parallelism with different ways of programming support. A more detailed description is given for the TwoL(two level) approach with its compiler support and the TLib approach with a library interface. Moreover, we present extensions to the parallel programming with M-tasks that have been proposed recently. The scheduling and mapping of M-tasks with dependencies is an important method to get efficient versions of an M-task program. Thus, we present mapping techniques for M-task programs and finish the chapter with measurements of numerical codes on up-to-date multi-core clusters.
TASK-BASED PROGRAMMING APPROACHES Several approaches have been proposed for the use of M-tasks for programming large parallel systems including language extensions as well as skeleton-based, library-based and coordination-based approaches. We give an overview of these approaches in the following subsections.
Language Extensions Language extensions enrich existing programming languages with additional annotations or language constructs to support a mixed task and data parallel execution. The host languages are often data parallel languages that are extended to support task parallelism or task parallel languages with support for data parallelism. A special compiler is required to translate the language extensions. Most approaches use a source-to-source compiler which creates a program in the host language that utilizes a runtime library to realize the extensions. Fortran M (Foster & Chandy, 1995) is a task parallel language based on Fortran 77. Language constructs are provided for creating processes and communication channels that enable one-to-one communication between processes based on a message passing paradigm. The process model is dynamic, i.e., new processes and communication channels can be created at runtime. Fortran D(Fox, Hiranandani, Kennedy, Koelbel, Kremer, & Tseng et al., 1990) and High Performance Fortran (HPF)(High Performance Fortran Forum, 1993) are data parallel languages based on Fortran 90 that include primitives to distribute arrays among processors and data parallel operations such as array expressions and parallel loops. The integration of Fortran M with either Fortran D or HPF is described in (Chandy, Foster, Kennedy, Koelbel, & Tseng, 1994). Fortran M is responsible for resource management, e.g. starting the data parallel tasks that are executed on processor groups specified by the user, and Fortran D or HPF takes care of the distribution of computations and data structures on these groups. Two concurrently executed data parallel tasks can communicate with each other using send and receive operations on a channel that has to be provided by the parent task. Opus (Chapman, Mehrotra, van Rosendale, & Zima, 1994; Chapman et al., 1997) defines a set of extensions to the data parallel HPF language to support the coordination of multiple independent data parallel modules. Target applications of Opus are coarse-grained multi-disciplinary simulations consisting of independent program parts that periodically exchange information, e.g. for the simultaneous optimization of the aerodynamic and structural design of an aircraft configuration. Task parallelism in Opus is realized by special subroutines that may be invoked onto a specific set of processor resources
248
Mixed Programming Models Using Parallel Tasks
that has to be provided by the user. The heart of the Opus extensions are ShareD Abstractions (SDAs) that are objects encapsulating data and methods. An SDA may be shared by multiple tasks thus supporting communication and coordination between these tasks. The framework OpusJava(Laure, Mehrotra, & Zima, 1999; Laure, 2001) has been proposed to integrate Opus components into larger distributed Java based environments and thus providing support for loosely coupled heterogeneous platforms. Braid (West & Grimshaw, 1995) adds data parallelism to the object-oriented Mentat task parallel language. Mentat is based on C++ and provides high-level abstractions to define task parallel objects. The Mentat system handles the dynamic creation, communication, synchronization, and scheduling of these objects. Braid additionally supports data parallel objects that include overlay methods to initialize data, aggregate methods to apply operations on all or a subset of the data elements, and reduction methods to distill information from the values of the data set. The user can provide annotations to inform the compiler and runtime system about the communication behavior of the objects. This includes local communication within data parallel methods, e.g. nearest neighbor communication pattern and the interaction between objects and which operations are dominant. The runtime system realizes the distribution of the data based on the user’s annotations and platform specific characteristics. Fx (Subhlok & Yang, 1997) is a Fortran-based language that integrates directives to partition and layout data similar to HPF and directives to control task parallelism. Task parallelism can be exploited within specific areas of the program called task regions. Within a task region subroutine calls can be executed in a data parallel way by a subset of the available processors. The size and layout of the processor subsets can be computed at runtime. Each subroutine may contain additional task regions, thus providing support for nested parallelism. The Fx framework includes a mapping tool to compute an optimized task placement based on a dynamic programming approach (Subhlok & Vondran, 1995). The required cost information are obtained by executing the program with different mappings. High Performance Fortran 2.0 (HPF 2.0) (High Performance Fortran Forum, 1997) is a language extension based on Fortran 95 including approved extensions for a mixed task and data parallel execution. The utilized task model is similar in spirit to the Fx approach. The task region construct provides support for creating independent coarse-grained tasks, each of which can itself execute data parallel or nested task parallel computations. The on directive allows the programmer to control the distribution of computations among the processors of a parallel machine. The distribution of the data on processor groups and subgroups is supported by the distribute and align directives. The shape of the utilized processor groups can be computed at runtime. Orca (Ben Hassen, Bal, & Jacobs, 1998) defines a specification language that is translated into C code utilizing a special runtime library. Data parallelism is available in form of partitioned objects that may be distributed over multiple processors. Data parallel computations are performed using the owner-computes rule and communication operations to access remote data are inserted by the compiler. Task parallelism is expressed by using processes that can be started dynamically. The data distribution for partitioned objects and the processors for the execution of a task have to be explicitly coded by the programmer. The communication between processes is supported by shared objects that are implemented as instances of abstract data types. Each process can read and modify data within the shared objects by using atomic operations, thus enabling data exchanges between concurrently executing processes. Spar/Java (van Reeuwijk, Kuijlman, & Sips, 2003; Sips & van Reeuwijk, 2004) defines language extensions for Java that are translated to C++ code by the Timber compiler using the Vnus language as an intermediate step. The compiler includes special optimizations for multi-dimensional arrays. The language extensions provide annotations to explicitly distribute data and computations. The syntax of
249
Mixed Programming Models Using Parallel Tasks
these annotations is similar to functional languages. The foreach construct defines data parallel computations, e.g. operations on array elements. The each construct defines data independence for a set of statements and therefore enables a task parallel execution. The executing processors can be specified for each statement using the on annotation. Fortress (Allen, Chase, Hallett, Luchangco, Maessen, & Ryo et al., 2008), Chapel (Chamberlain, Callahan, & Zima, 2007) and X10 (Charles, Grothoff, Saraswat, Donawa, Kielstra, & Ebcioglu et al., 2005) are new parallel programming languages that are currently under development. The underlying programming models provide a higher level of abstraction than the previously mentioned approaches and are targeted to increase the productivity of the programmers. The memory is assumed to be globally shared by all program parts; necessary communication operations have to be automatically determined by the compiler. Fortress is an object-oriented language that expresses parallel computations with implicit and explicit threads. Explicit threads are created by the programmer; implicit threads are created by parallel language constructs, e.g. also-do blocks to define independent computations for task parallelism or for loops which are parallel by default and can be executed in a data parallel way. The parallel target platform is modeled by regions that can be hierarchically nested; threads can be assigned to specific regions by the user to increase the performance. Currently, Fortress is only available for shared memory platforms but an extension for distributed memory systems is planned. Parallel platforms in the Chapel language can be described by a set of locales, e.g. a locale per cluster node. Data and computations can be mapped on locales using the on clause. Data parallelism in Chapel is expressed by domains that define the size and shape of arrays. Domains can be distributed among locales. Data parallel operations on array elements can be expressed using the forall loop, or the reduce and scan functions. Task parallelism is supported by the cobegin directive that expresses independent computations. X10 is based on a partitioned global address space (PGAS) memory model that is represented by a set of places. Multiple activities may be executed concurrently by different places. The async statement supports the creation of asynchronous activities on specific places. These activities can be synchronized using by the finish statement. X10 supports multi-dimensional arrays that may be distributed among a set of places using pre-defined or user-defined distribution types. Data parallel operations on arrays can be performed using the ateach construct.
Skeleton-Based Approaches Skeleton-based approaches include a predefined set of coordination patterns to combine sequential code or small parallel program fragments into complex parallel applications. Parallel skeletons can provide support for data parallel computations, e.g. mapping the same code onto different parts of the input data, or for task parallel computations, e.g. arrange different tasks in form of a pipeline. Multi-level parallelism is supported by nesting different skeletons within each other. P3L (Pelagatti, 2003) is a skeleton coordination language using C as a host language that is used to express the sequential portions of the application. The supported skeletons include data parallel, task parallel and control skeletons that can be nested within each other. Data parallel skeletons are map to distribute data and to apply a specific skeleton to each data element, reduce to combine distributed data into a single value, scan to compute the parallel prefix of an array, and comp for functional composition. The task parallel skeletons operate on streams of input data; pipe applies a sequence of skeletons to the
250
Mixed Programming Models Using Parallel Tasks
input data one after another forming a pipeline and farm applies the same skeleton to different items of the input data stream. Control skeletons are seq for wrapping sequential code and loop for the repeated execution of another skeleton. P3L includes a compiler for the generation of C+MPI programs that utilize a library which provides optimized implementation templates for each skeleton. A cost expression for each skeleton is available and, thus, the costs for the entire application can be determined by combining these cost expressions according to the hierarchical structure of the application. The costs for the sequential fraction of the code are obtained by profiling. taskHPF (Ciarpaglini, Folchi, Orlando, Pelagatti, & Perego, 2000) uses a two-tier model for combining task and data parallelism. The task parallel coordination structure is described by a high-level language that includes the definition of data parallel tasks with input and output parameters and the interaction between tasks based on predefined skeletons. Available skeletons are the pipeline pattern and the replicate directive to create multiple incarnations of non-scalable stages. The specification language includes the on processors directive to define the number of executing processors for each data parallel task. HPF is used to implement the data parallel tasks and to describe data distributions within these tasks. Necessary re-distribution operations between data parallel tasks are identified by the compiler and are realized by the COLTHPF (Orlando & Perego, 1999; Orlando et al., 2000) coordination layer. LLC (Dorta, González, Rodriguez, & de Sande, 2003; Dorta, López, & de Sande, 2006) is a highlevel parallel language with support for algorithmic skeletons. The host language is C augmented with OpenMP-like directives to define skeletons and to provide additional information to the compiler. The compiler llCoMP translates this code into a parallel C+MPI program. Basic data parallel skeletons in LLC are forall to define parallel loops and taskq to define task farms. Task parallelism is provided by the sections skeleton to define independent computations and the pipeline skeleton to describe pipelined computations. The implementation of the basic skeletons partitions the available processors into a number of subgroups equal to the number of tasks, e.g. number of pipeline stages or loop iterations. The mapping of tasks onto processor groups can be controlled by assigning weights. ASSIST (Vanneschi, 2002) is a framework for the skeleton-based composition of sequential and parallel modules into complex applications. Sequential modules are provided in a host language of ASSIST (C, C++, and Fortran) and operate on streams of input data. Parallel modules are expressed by the parmod construct that defines the input and output streams, a set of virtual processors and a virtual processor topology. Additionally, modules can access external objects that may be declared as shared, thus supporting data exchanges between concurrently executing modules. The interaction between the modules in form of a directed graph is described in the ASSIST-CL coordination language. The nodes of the graph correspond to components and the edges are data streams that are communicated between components. For program execution, the virtual processors of the parallel modules have to be mapped onto physical processors. This mapping can also be reconfigured at runtime (Vanneschi & Veraldi, 2007). Lithium (Aldinucci, Danelutto, & Teti, 2003) is a Java-based programming environment for the development of structured parallel applications based on a set of predefined skeletons provided in form of a library. A variety of skeletons is supported, e.g. the data parallel map and divide-&-conquer, the task parallel farm and pipe and control skeletons to model loops and conditionals. The execution of a Lithium application is based on a master-slave approach: the master contains a task pool with all executable tasks that are distributed to the slave nodes. DIP (Diaz et al., 2003) is a pattern-based coordination language with focus on domain decomposition and multi-block applications, e.g. solution methods for PDEs. The implementation of DIP is based on the border-based coordination language BCL (Diaz, Rubio, Soler, & Troya, 2002), i.e., the DIP compiler
251
Mixed Programming Models Using Parallel Tasks
translates a DIP specification program into a BCL program. BCL supports the solution of numerical problems with multiple domains by automatically creating necessary border-exchange operations between domains. Basic data parallel tasks are implemented in HPF. DIP provides the multiblock pattern to describe a fixed number of k-dimensional domains with fixed boundary coordinates that require a periodic exchange of border values. Additionally, the pipe pattern to describe a chain of pipeline stages and the replicate directive to create multiple independent incarnations of a pipeline stage each operating on different data from the input stream are available. DIP supports multiple implementation templates for each pattern. The programmer is responsible for selecting an appropriate template and for specifying the number of processors to execute each task. SBASCO (Diaz, Rubio, Soler, & Troya, 2004) is an enhancement of the DIP approach that similarly supports the multiblock, pipe and farm skeletons. Additionally, SBASCO includes a cost model for the estimation of the execution time of each skeleton depending on hardware parameters. SBASCO distinguishes two different views on the specification, the application view and the configuration view. The application view describes the structure of the application using the available skeletons and the basic data parallel components with their input and output parameters. The configuration view extends the application view with information on data distributions, processor layout and the internal structure of the components. The application view is provided by the programmer; the configuration view is used by a configuration tool to obtain an efficient allocation of the different application components on parallel platforms based on the cost model enhanced by a run-time analysis.
Library-Based Approaches Library-based approaches provide library routines to support task and data parallel executions. This includes the support of coordination and synchronization of multiple data parallel tasks, the provision of data re-distribution routines, the creation of processor groups and the execution of tasks on the correct processors. HPF/MPI (Foster, Kohr, Krishnaiyer, & Choudhary, 1996) is a library that provides an HPF binding to the MPI message passing library and thus enables HPF programs to issue MPI communication operations. Therefore, the coordination and synchronization of different concurrently executing programs is supported. Arbitrary variables defined in the HPF program can be used as parameters for the communication operations provided. These variables may be distributed among the processors executing the data parallel module and therefore the implementation of the library has to deal with arbitrary distributed data structures. For example, a point-to-point communication operation between two modules has to handle the case of different source and target distribution types. This is realized using a descriptor exchange to exchange distribution information between communicating modules. HPF_TASK_LIBRARY (Brandes, 1999) enables the interaction of data parallel HPF tasks during their execution time by providing point-to-point and collective communication operations. The library is designed for the HPF 2.0 task model that supports the creation of data parallel tasks on disjoint processor groups but does not allow communication between concurrently executed tasks. The library supports the exchange of data structures that are distributed among multiple processors. Therefore, the distribution information has to be exchanged prior to the data transmission to determine the resulting communication pattern. Nested parallel executions are supported, but only tasks on the same nesting level may communicate with each other.
252
Mixed Programming Models Using Parallel Tasks
Figure 1. Decomposition of the set of processes V={1,2,..,9} into a two-dimensional grid and executing a group-SPMD phase using vertical processor groups (left) and horizontal processor groups (right).
KeLP-HPF (Merlin et al., 1999) uses the C++ class library KeLP (Fink, 1998) to coordinate multiple data parallel HPF tasks. KeLP provides high-level abstractions to simplify the development of blockstructured algorithms on SMP clusters. KeLP builds on MPI and includes mechanisms to manage data layout, data motion and the parallel control flow. For the data layout, general block decompositions are supported and the communication schedules are determined at runtime. In the KeLP-HPF programming model, KeLP can dynamically create processor groups and start new HPF tasks. Thus, the programming model is especially suited for applications that execute regular data parallel operations on an irregular or dynamic domain, e.g. multi-block codes or adaptive refinement methods. The arguments for the data parallel tasks are provided by KeLP in a distributed format along with a mapping descriptor that informs the HPF code of the distribution type. The library ORT (Rauber, Reilein-Ruß, & Rünger, 2004a) supports the programming for applications with a two or higher dimensional task grid and task dependencies mainly aligned in the dimensions of the task grid. Examples are algorithms from linear algebra based on two or higher dimensional arrays, like the LU decomposition. The programming model of the ORT library is based on a group-SPMD model in which the set of processors is subdivided into a set of disjoint groups of processors and each processor groups executes a parallel task in parallel to the other groups. In the programming model of the ORT library there exist several partitions of the entire set of processors in disjoint groups with the specific property that the groups are orthogonal to each other in a two or higher dimensional grid; Figure 1 shows the two-dimensional case. A typical ORT program consists of computation phases and communication phases. Each phase is executed on exactly one of the processor decompositions and performs either group-SPMD computation on the decomposition or a communication within the groups. During the execution of the ORT program the active processor decomposition changes from phase to phase such that different tasks cooperate in the group-SMPD way. The ORT library calls support the building of processor decompositions based on MPI and the mapping of task to the processors groups. The orthogonal way of communication can speed up the communication phases of an application and it is useful to integrate it in a hierarchical model as it will be described as an extended programming model in a subsequent section of this article.
253
Mixed Programming Models Using Parallel Tasks
Coordination-Based Approaches Coordination-based approaches are based on a static task structure that might be provided in form of an explicit specification of the available parallelism. A compiler or a transformation-based toolset can be used to translate the specification into executable code. In contrast to language extensions, the complete structure of the application is visible to the compiler and optimizations like scheduling can be applied. Paradigm (Joisha & Banerjee, 1999) is a parallel research compiler framework for HPF programs that additionally supports task parallel extensions proposed in (Ramaswamy et al., 1997). The extensions include annotations in the program source that enable the automatic extraction of the task parallel structure of the application in form of a macro dataflow graph (MDG). The MDG has a hierarchical structure with simple nodes representing computation, loop nodes (for or while), conditional nodes(if) and user-defined nodes, edges symbolize data dependencies. The MDG is annotated with cost parameters for simple nodes and possible data re-distribution operations resulting from data dependencies. The node costs are determined by profiling and fitting the obtained results to a curve according to Amdahl’s law. The costs for data re-distribution operations depend on the size of the transmitted data, the overhead for sending and receiving data, and the transmission time of the network. The Paradigm framework includes scheduling support to map MDGs on a specific target platform. Two scheduling algorithms, TSAS and SAS, are available (Ramaswamy, 1996). The final stage is the generation of an optimized MPMD code that utilizes a data re-distribution library for multi-dimensional arrays. The communication pattern and the communication schedule of the re-distribution operations are calculated at runtime using the FALLS algorithm (Ramaswamy, Simons, & Banerjee, 1996). Network of Tasks (Pelagatti & Skillicorn, 2001) is a programming model that defines a coordination language for coarse-grained tasks with an emphasis on runtime prediction. An application is modeled as a directed acyclic graph with nodes being arbitrary parallel programs that may be heterogeneous. The nodes are adaptive, i.e., different implementations may be available and the number of executing processors can be modified. The directed edges of the graph indicate one-way communication with parallel data structures or streams. The scheduling of the task graph on a target platform is performed by a work-based allocation technique (Skillicorn, 1999). Pipelining and farming are used to increase application performance in case there are enough processors available. Pipelining allows the simultaneous execution of all nodes of a subgraph, e.g. iterations of a loop, and farming increases the effective parallelism by replicating non-scaling nodes. The costs for the entire application are composed of the costs for the nodes that are provided by the user and the costs for the communication that are derived using the BSP model. S-Net (Grelck, Scholz, & Shafarenko, 2007) is a stream-based coordination language to combine data parallel modules implemented in SAC. SAC is a side-effect free functional language that supports data parallel operations on n-dimensional stateless arrays. S-Net treats data parallel SAC programs as stateless boxes operating on input streams and producing an output stream. On arrival of an item on the input stream the box is expected to apply its operation and produce one or more output items on a single output stream. In S-NET, the functionality of these boxes is defined using a box signature that maps the input type to output types. Four constructors are available to hierarchically compose boxes into complex networks. The static serial composition connects two networks A and B by connecting the output of A with the input of B. The static parallel composition of two networks A and B sends input items depending on their types either to A or B and merges the output streams of A and B. The serial and parallel replicators support the
254
Mixed Programming Models Using Parallel Tasks
repeated execution of a network A where the iterations are connected via serial composition or parallel composition, respectively. A compiler for S-NET programs for shared memory platforms is currently under development. The performance-aware composition framework (Kessler & Löwe, 2007) supports the combination of parallel and sequential components into parallel applications with an emphasis on performance prediction. Each component is required to provide a functional interface specifying the parameters and a performance interface that contains information on the execution time depending on the number of executing processors. For each component there may exist multiple parallel or sequential implementation variants that share the same functional interface but define separate performance interfaces. The implementation of the parallel variants may be based on an SPMD programming model. The structure of the application is defined using a host language extended by annotations that are evaluated by a composition tool. Parallel components may include compose_parallel operators that mark independent invocations of components, i.e., any sequential or parallel execution order is valid. Calls to components outside this operator are assumed to be executed sequentially in the specified order. The execution of the target application is based on a static variant dispatch table that is created by the composition tool. This table contains the optimal implementation variant for each combination of component and processor number. Additionally, this table contains a schedule for each compose_parallel operator for each number of executing processors. The schedule is determined using scheduling techniques for independent M-tasks and specifies the execution order and sizes of processor groups. At runtime, the optimal schedule or implementation variant is selected depending on the actual problem size and number of available processors. A prototype compiler using the C-based parallel language Fork for the implementation of the components has been realized.
HIERARCHICAL M-TASK PROGRAMMING In this section, we present hierarchical programming approaches for mixed programming with parallel tasks. In particular, we describe the library TLib (task library), as well as the coordination model TwoL (two level) which is based on a specification language for the hierarchical composition of tasks.
TwoL Model Support for the programming with parallel tasks (called modules) can also be provided in form of a coordination approach. The TwoL (two level) model (Rauber & Rünger, 1996, Rauber & Rünger, 2000) is a top-down method for the development of applications that distinguishes two well separated layers of parallelism. The lower (data parallel) level defines the interfaces of modules that are provided by the application developer. These basic modules are treated as black-box SPMD codes that can be executed on an arbitrary number of processors. For each basic module there may be multiple implementation variants differing in the data distribution of the parameters or the employed algorithm. The upper (task parallel) level defines composed modules that are hierarchically composed of other modules. The structure of the composed modules is defined in the platform independent TwoL-specification language. The specification of a composed module is based on a module expression consisting of invocations of modules (as basic elements) and a set of coordination operators that specify data dependence or data independence between subexpressions. The ||-operator combines independent computations for
255
Mixed Programming Models Using Parallel Tasks
which both, a concurrent and a consecutive execution are possible. The °-operator demands the subsequent execution of computations due to data dependencies that may lead to data re-distribution operations. Sequential loops can be defined using the for and while operators and parallel loops are specified using the parfor operator. A data dependence between the iterations of sequential loops is assumed whereas the iterations of parallel loops are independent from each other and can be computed concurrently. The conditional execution of subexpressions is supported by the if operator. The initial TwoL-specification of an algorithm defines the maximum degree of available task parallelism. For an execution on a specific target platform, the actual degree of task parallelism that should be exploited and the data distributions of the modules need to be fixed. These decisions are made by several incremental transformation steps resulting in a non-executable parallel frame program. The parallel frame program does not include any platform-dependent information, but different platforms may require different frame programs to achieve a good performance. The final transformation step of the TwoL framework translates the parallel frame program into an executable message passing program. The generated program is responsible for the creation of the correct communication context for the execution of the basic modules, e.g. by using communicators provided by MPI, and a correct dataflow between modules by inserting data re-distribution operations at the appropriate positions. The design steps in the derivation of an efficient parallel frame program are based on a cost model that has to provide accurate predictions for the execution times of modules depending on the number of executing processors and for the data re-distribution operations between modules depending on the source and target processor groups and distribution types. For the basic modules, a cost model based on parameterized runtime formulas is employed. These closed-form symbolic formulas consist of a term describing the execution times of the arithmetic operations and functions that describe the runtime of the internal communication operations such as single-transfer and broadcast operations. The platform-independent structure of the runtime formulas can be derived by inspecting the program text. The compiler tool SCAPP (Kühnemann, Rauber, & Rünger, 2004) has been developed to automate this task. The platform-specific parameters of the formulas can be determined through profiling techniques. Date re-distribution costs are modeled using a platform-dependent startup time and byte-transfer time of the interconnection network. For composed modules, the runtime functions are composed according to the hierarchical structure of the module. (See Figure 2) The scheduling step of the TwoL framework determines an execution order for independent modules, assigns processors to modules and load balances processor groups. For this step, the specification program is transformed into a global module dependence graph (MDG) that captures the data dependencies between modules. The MDG is a directed acyclic graph that exhibits a series-parallel (SP) structure, Figure 3 (left) shows an example. For the scheduling and load balancing, the TwoL-Level (Rauber & Rünger, 1998) and the TwoL-Tree (Rauber & Rünger, 1999b) algorithms have been developed and implemented in a scheduling toolkit (Dümmler, Kunis, & Rünger, 2007a). The runtime of a TwoL program may also be influenced by the choice of the data distribution for the input and output parameters of the modules. Therefore, the TwoL framework includes support for the automatic derivation of suitable data distributions. The derivation process uses a dynamic programming approach that determines the optimal distribution types by exploiting the hierarchical structure of the application (Rauber, Rünger, & Wilhelm, 1995). The core concepts of the TwoL model have been implemented in form of a compiler tool (Rauber, Reilein-Ruß, & Rünger, 2004b; Reilein-Ruß, 2005).
256
Mixed Programming Models Using Parallel Tasks
Figure 2. Illustration of the hierarchical structure of a TLib program. M-task M1 consecutively executes M2, M3 and M13; M3 concurrently executes M4 and M9; M4 executes M5 and M6 one after another, where M6 further subdivides the available processors to excute M7 and M8 in parallel; M9 consists of the sequential execution of M10, M11, and M12.
Figure 3. Illustration of a task graph representing an M-task application in the TwoL model (left) and a possible CM-task graph (right)
257
Mixed Programming Models Using Parallel Tasks
Programming Interface Tlib The runtime library TLib has been developed to support the programming with hierarchically structured M-tasks. TLib library functions are designed to be called in an SPMD manner which results in multilevel group-SPMD programs. The entire management of groups and M-tasks at execution time is done by the library. Thus, the TLib API provides support for: a. b. c. d.
The creation and administration of a dynamic hierarchy of processor groups; The coordination and mapping of nested M-tasks to processor groups; The handling and termination of recursive calls and group splittings; The organization of communication between M-tasks.
Internally, the library uses distributed information stored in distributed descriptors which cannot be accessed directly by the user, thus hiding the complexity of the group management and the multi-level group-SPMD organization. This relieves the application programmer from realizing the technical details of hierarchical M-tasks and the corresponding group management and allows him to concentrate on how to exploit the potential M-task structure of the given application. The current version of the library is based on C and is built on top of MPI. A TLib program consists of: a. b.
A set of basic functions expressing M-tasks that are executed in an SPMD style and that comprise the computations to be performed; A set of coordination functions to control the execution of the basic functions.
The processors executing a basic M-task can exchange information with arbitrary MPI operations. The coordination functions allow a concurrent execution of basic M-tasks by the activation of suitable library functions. The coordination functions can be nested arbitrarily. Thus, a coordination function can assign other coordination functions to subgroups of processors for execution, which can then again split the corresponding subgroup and assign other coordination functions. A basic M-task function F is expressed as a function of the form, void *F (void * arg, MPI_Comm comm, T_Descr * pdescr)
where the parameter arg comprises the arguments used by F; the parameter comm specifies an MPI communicator which can be used for internal communication within the M-task F; pdescr is a reference to a TLib group descriptor containing information about the processor group onto which F is mapped. This descriptor can be used to dynamically split this processor group further in the body of F, if F exhibits an internal task parallel structure. F may also generate a recursive call of itself on a smaller subgroup, thus enabling the implementation of divide-and-conquer algorithms. The TLib library provides functions for initialization, splitting of groups into two or more subgroups, assignment of tasks to processor groups, and getting information on the subgroup structure. An example of a library function for splitting a processor group into two processor groups is,
258
Mixed Programming Models Using Parallel Tasks
int T_SplitGrp(T_Descr *pdescr, T_Descr *pdescr1, float per1, float per2)
where pdescr is a reference to the group descriptor of the original group and pdescr1 is a reference to a new group descriptor that is generated by the library function. The parameters per1 and per2 specify fractional values with per1 + per2 ≤ 1. The effect of the operation is a splitting into two disjoint processor groups with a percentage of per1 or per2 of the processors of the original group, respectively, as specified by the parameter pdescr. More splitting operations are provided, allowing, e.g., the splitting into an arbitrary number of processor groups. After a splitting operation generating a number of subgroups, M-tasks can be assigned to the newly generated subgroups by corresponding mapping functions. An example for a mapping operation onto two processor groups is, int T_Par(void *(*F1)(void *, MPI_Comm, T_Descr *), void *parg1, void *pres1, void *(*F2)(void *, MPI_Comm, T_Descr *), void *parg2, void *pres2, T_Descr *pdescr) where F1 and F2 describe the M-tasks to be mapped to the subgroups and to be executed concurrently by the subgroups; parg1 and parg2 are the parameters for F1 and F2, respectively; pres1 and pres2 are the results produced by F1 and F2, respectively; the subgroups are described by the parameter pdescr. More mapping operations are provided to assign M-tasks to an arbitrary number of subgroups. Figure 2 shows an example for the emerging hierarchical structure of TLib programs. A detailed description of the TLib library is given in (Rauber & Rünger, 2005) along with example applications demonstrating the use of the library. The use of TLib for specifying efficient parallel implementations for matrix multiplication based on the Strassen algorithm has been described in (Hunold, Rauber, & Rünger, 2004). A data re-distribution library DRDLib to support re-distributions between cooperating M-tasks using TLib has been described in (Rauber & Rünger, 2006).
ExTENDED PROGRAMMING MODEL In the TwoL programming model two modules M1 and M2 can only communicate in-between their execution, i.e. the module supplying the data has to finish its execution and the module consuming the data must not have started. For applications that require periodic data exchanges between program parts, it might also be beneficial to allow further data exchanges during the execution of concurrently executed modules. Examples for such applications are time stepping methods that perform a data exchange at the end of each time step. An implementation using the TwoL programming model restricts the modules to the execution of a single time step and, thus, limits the possible granularity of the modules. A more natural way to structure such applications is to combine multiple time steps within a module and to sup-
259
Mixed Programming Models Using Parallel Tasks
port communication between running modules to perform the required data exchanges. In the following, we present an extended programming model that follows this idea and discuss programming support for the development of efficient parallel implementations in this model.
CM-Task Programming Model The programming model of communicating multiprocessor-tasks(CM-tasks) (Dümmler, Rauber, & Rünger, 2007) extends the TwoL model by providing support for communication between concurrently executed modules. CM-tasks are parallel modules which have a set of input and output parameters and support the execution on an arbitrary number of processors. The interactions between CM-tasks are expressed by P-relations and C-relations: •
•
Precedence relations (P-relations) capture the input/output dependencies between CM-tasks. A P-relation between CM-tasks A and B denotes that A produces output data required as an input for B and might lead to a data re-distribution operation between A and B when A and B are executed on different subsets of the processors or if A provides its output data in a different distribution than expected by B. These are the dependencies captured in the original TwoL model. A communication relation (C-relation) between CM-tasks A and B denotes that A and B have to communicate with each other during their execution. This is an extension of the TwoL model since modules can now communicate during their execution, if they are connected with a C-relation.
The structure of a CM-task program can be represented by a CM-task graph G = (V, E) where the set of nodes V corresponds to the set of CM-tasks. The set of edges E = E p Ec consists of the set of directed edges Ep representing P-relations and the set of bidirectional edges Ec symbolizing C-relations. Figure 3 (right) shows an illustration of a CM-task graph. The possible execution orders of the CM-tasks are limited by the P-relations and C-relations. A P-relation connecting CM-tasks A and B requires that the execution of A must have been finished and all required data re-distributions between A and B must have been carried out before B can be started. CM-tasks connected by a C-relation must be executed concurrently by disjoint subsets of the processors to perform the specified data exchanges. Therefore, there cannot be both a P-relation and a C-relation between CM-tasks A and B and hence E p Ec = Æ . Examples for CM-task programs are iterated Runge-Kutta (IRK) methods (van der Houwen & Sommeijer, 1991; Rauber & Rünger, 1999a) and Parallel Adams methods (van der Houwen & Messina, 1999) that are time-stepping methods for the solution of initial value problems of non-stiff ODEs. Due to data dependencies between successive time steps, each time step of these applications has to be computed by a separate set of modules in the TwoL model. Using the CM-task model, successive time steps can be combined within a single set of CM-tasks and data dependencies between time steps are modeled by C-relations. This enables the CM-task version to exploit optimized communication patterns. Examples are the orthogonal arrangement of the processes (cf. Figure 1) and the use of concurrent multi-broadcast operations to realize the data exchanges between the CM-tasks. Benchmark results comparing a pure M-task based implementation with a CM-task version are presented at the end of this chapter.
260
Mixed Programming Models Using Parallel Tasks
Figure 4. Overview of the incremental transformation steps used to create an executable CM-task coordination program
Development of CM-Task Programs Support for the development of CM-task programs has been proposed in form of a compiler framework (Dümmler, Rauber, & Rünger, 2008a). The framework consists of several consecutive transformation steps and supports the incremental creation of an executable coordination program from an initial specification of the structure of the CM-task application using the non-executable, platform-independent specification language. Each transformation step of the framework adds additional information resulting in an augmented specification. The specification language supports the definition of basic CM-tasks whose implementation has to be provided by the application developer and composed CM-tasks whose structure is visible to the framework. Composed CM-tasks consist of CM-task activations and control constructs guiding the control flow, i.e. conditional execution (if-statement), the repeated execution with data dependencies (while-loop, for-loop) and without data dependencies between loop iterations (parfor-loop). The transformation process is depicted in Figure 4 and consists of four consecutive steps. The first step, the Dataflow Analyzer, takes the initial specification of a parallel algorithm as an input. The data dependencies in this specification program are defined implicitly using input/output parameter lists and variable names. The Dataflow Analyzer is responsible for uncovering these dependencies and inserting the appropriate P-Relations and C-Relations. The successive transformation step, the Scheduler, requires additional information about the target platform that is provided in form of a Machine Description. This input file specifies the number of available processors and contains approximations of the computational power, i.e. the average time required to execute an arithmetic operation, and the communication performance, i.e. the startup and byte-transfer
261
Mixed Programming Models Using Parallel Tasks
time of the interconnection network. The output of the Scheduler is a platform-dependent specification program with annotations that define the execution order and the executing processor groups for each CM-task invocation. The Data Manager inspects all P-relations and uses the computed schedule for the CM-task program to decide which data re-distribution operations are required for a correct execution. The Code Generator creates the final message passing program in the target language. The created coordination program consists of: •
• • •
The execution of CM-tasks on the processor groups computed by the scheduler; basic CM-tasks are provided by the user in form of a library and the coordination code for composed CM-tasks is created by the framework, The execution of data re-distribution operations between CM-tasks; the communication pattern is statically computed by the framework and included in the coordination program; Coordination constructs (loops, conditions) according to the input specification; Processor group management code that creates the correct MPI communicators for communication between concurrently executed CM-tasks as specified by the C-relations and for the execution of CM-tasks and data re-distribution operations.
A prototype realization of the transformation framework as a compiler tool for the C target language is available.
SCHEDULING AND MAPPING A suitable schedule is crucial to obtain the maximum performance of an M-task application. For homogenous platforms, the schedule defines the execution order of the M-tasks and the number of executing processors. Unfortunately, the M-task scheduling problem of determining the optimal schedule that leads to the lowest execution time is NP-complete. Therefore, several research groups have proposed scheduling heuristics and approximation algorithms to automatically determine a good schedule. Examples are TwoL-Level (Rauber & Rünger, 1998), TwoL-Tree (Rauber & Rünger, 1999b), CPR (Radulescu, Nicolescu, van Gemund, & Jonker, 2001), CPA (Radulescu & van Gemund, 2001), iCASLB (Vydyanathan, Krishnamoorthy, Sabin, Çatalyürek, Kurç, & Sadayappan et al., 2006a) and Loc-MPS (Vydyanathan, Krishnamoorthy, Sabin, Çatalyürek, Kurç, & Sadayappan et al., 2006b), see (Dümmler, Kunis, & Rünger, 2007b) for a comparison. For heterogeneous platforms, the schedule additionally has to define the mapping of M-tasks onto specific processors. Scheduling heuristics for large heterogeneous cluster-of-cluster platforms restrict the execution of an M-task to a single homogeneous subcluster, but each subcluster is allowed to execute multiple M-tasks concurrently. Examples are M-HEFT (Suter, Desprez, & Casanova, 2004) and HCPA (N’takpé & Suter, 2006), see (N’takpé, Suter, & Casanova, 2007) for a comparison. Multi-core and SMP clusters are heterogeneous platforms that are built up of a set of homogeneous processing cores interconnected by a heterogeneous network. For these systems, the scheduling can be performed by two consecutive steps (Dümmler, Rauber, & Rünger, 2008b): 1.
262
Scheduling the M-task graph describing the application on a set of homogeneous symbolic cores whose computing performance is equal to the physical cores of the target platform but a homogeneous
Mixed Programming Models Using Parallel Tasks
Figure 5. Illustration of a tree-structure representing the architecture of a multi-core SMP cluster (left) and the use of the Dewey notion to label the computing elements (right).
2.
interconnection network is assumed and Mapping the symbolic cores used for the scheduling decisions onto physical cores.
The scheduling step is similar to homogenous scheduling algorithms. In the following, we concentrate on the mapping step that has to define a mapping for each point in time, i.e. there has to be an assignment of the symbolic cores of the currently executing M-tasks to the physical cores of the architecture. For each M-task, the mapping is fixed, i.e. during its lifespan an M-task is executed by the same set of physical cores. The multi-core target architecture is represented in a tree structure with cores C as leaves, processors P as intermediate nodes that combine cores, computing nodes N as intermediate nodes that combine processors, and the entire architecture A as a root node. The levels of the tree correspond to different interconnection networks. For a unique identification of the physical cores within the tree structure we use the Dewey notation (Knuth, 1975). Each node n gets a label l(n) that describes the path from the root node to the specific node. The root node r gets label l(r) = 0. The label l(n) of a node n consists of the label of the parent node m concatenated by the digit i, if n is children i of m, i.e. l(n) = l(m).i. Figure 5 illustrates the tree structure of the architecture and the use of the Dewey notation to describe multicore clusters. For the definitions of the mappings, we consider the situation that g independent M-tasks should be executed concurrently and the scheduling step has assigned the group of symbolic cores Gi to M-task Mi, i = 1,…,g with Gi G j = Æ for i ≠ j. The number of symbolic cores in group Gi is denoted as gi and has been determined in the scheduling step. The mapping is a function F : {G1,...G g } ¾ ¾® 2C where C denotes the set of physical cores. F maps the groups of symbolic cores to disjoint physical cores, i.e. F (Gi ) F (G j ) = Æ for i ≠ j and each symbolic group is mapped on a physical group with the same size, i.e. |F(Gi)|=|Gi|. For each proposed mapping we define a sequence of physical cores s1, s2,…,sm with m = p*c*n
assuming an architecture with c cores per processor, p processors per node and n total nodes. The mapping function F assigns the symbolic cores of a group Gi, i = 1,…,g to consecutive physical cores in
263
Mixed Programming Models Using Parallel Tasks
Figure 6. Illustration of a consecutive mapping (left) and a scattered mapping (right) for M-tasks {M1, M2, M3, M4} each requiring 4 symbolic cores on a platform with 4 nodes consisting of 2 dual-core processors.
this sequence, i.e. ìï i -1 ïü F (Gi ) = ïís j , s j +1,..., s j +gi -1 j = 1 + å gk ïý ïï ïï k =1 þ. î The Node-Oriented Consecutive Mapping tries to map the symbolic cores of an M-task onto the same cluster node. If an M-task does not fit on a single node of the architecture, multiple nodes are used. Figure 6 (left) shows an illustration of the consecutive mapping. The advantage of this mapping strategy is to enable shared memory optimizations for the implementation of the M-tasks, e.g. to speed up the internal communication by using optimized MPI libraries or to use a shared memory or hybrid programming model. In this mapping, the physical cores are ordered such that cores of the same node are adjacent, i.e. the sequence of physical cores is, 1.1.1,1.1.2,…,1.1.c,1.2.1,…,1.p.c.,2.1.1,…,2.1.c,…,n.p.c. The Scattered Core-Level Mapping assigns corresponding symbolic cores of different M-tasks onto the same cluster node. If the number of cores of the architecture exceeds the number of independent M-tasks, multiple symbolic cores of each M-task are mapped on the same node. The scattered mapping is illustrated in Figure 6 (right). This mapping strategy ensures an equal participation of all nodes in the internal communication of the M-tasks and can speed up data exchanges between M-tasks, especially in the case that only corresponding symbolic cores communicate with each other. In the sequence of physical cores the corresponding cores of neighboring nodes are adjacent, i.e. the sequence is given by 1.1.1, 2.1.1,..., n.1.1, 1.1.2, 2.1.2,..., n.1.c, 1.2.1,..., n.p.c . The Mixed Core-Level Mapping is a generalization of the consecutive and the scattered mappings. A parameter d, 1 ≤ d ≤ p*c describes the number of consecutive symbolic cores of an M-task that are mapped to the same cluster node. For d = 1 the scattered mapping results and setting d = p*c results in
264
Mixed Programming Models Using Parallel Tasks
the consecutive mapping. This mapping can be used to adapt to the ratio of communication within Mtasks and data exchanges between M-tasks. The sequence of physical cores is given by d -1 d -1 ).(1 + ((d - 1) mod c)), 2.1.1,..., n.(1 + ).(1 + ((d - 1) mod c)),..., c c 2d - 1 ).(1 + ((2d - 1) mod c)),..., n.p.c. 1.(1 + c 1.1.1, 1.(1 +
A suitable compiler tool can be used to integrate the mapping strategies in the code generation process. A realization using the MPI library can adapt the order of the processes within the appropriate communicators.
ExAMPLE AND ExPERIMENTS As example applications for an M-task based execution model we consider numerical codes. The first examples are solution methods for non-stiff ordinary differential equations(ODEs). We consider iterated Runge-Kutta (IRK) methods (van der Houwen & Sommeijer, 1991; Rauber & Rünger, 1999a) and Parallel Adams methods (van der Houwen & Messina, 1999) that have been developed for a parallel execution. The IRK method computes s stage vectors using m fixed point iteration steps with an implicit Runge-Kutta corrector. In the M-task programming model, each fixed point iteration step can be represented by s independent M-tasks but the M-tasks of successive steps cannot be combined due to data dependencies. The extended CM-task programming model provides another possibility to structure IRK methods. The computation of each stage vector is accomplished by a single CM-task that computes all fixed point iteration steps and performs the required data exchanges during its execution. The Parallel Adams methods include the explicit Parallel Adams-Bashforth (PAB) and the implicit Parallel Adams-Moulton (PAM) methods. The combination of the PAB and PAM methods in a predictor-corrector scheme results in an implicit ODE solver (PABM). Each time step of the PABM method involves the computation of K independent stage vectors each requiring group-based communication. At the end of a time step, a global data exchange is required to compute the next approximation vector. The M-task version of PABM uses K independent M-tasks each computing one of the stage vectors, but each time step requires a separate set of M-tasks. The extended CM-task model enables the adoption of a single set of CM-tasks that keeps running over all time steps. The second example comes from the area of solution methods for partial differential equations (PDEs) that operate on a set of meshes (also called zones). Within each time step, the computation of the solution is performed independently for each zone. At the end of a time step, a border exchange between overlapping zones is required. The NAS parallel benchmark multi-zone version (NPB-MZ) provides solvers for discretized versions of the unsteady, compressible Navier-Stokes equations that operate on multiple zones (van der Wijngaart & Jin, 2003). The fine grain parallelism within the zones is exploited using shared memory OpenMP programming; the coarse grain parallelism between the zones is realized using message passing with MPI. For the purpose of this article we consider a modified version of the Lower-Upper Symmetric Gauss-Seidel multi-zone (LU-MZ) benchmark which uses MPI for both levels of parallelism. This has the advantage that multiple nodes of a distributed memory platform can
265
Mixed Programming Models Using Parallel Tasks
Figure 7. Comparison of the execution times of a single time step of the IRK method using different execution schemes on the Xeon cluster (left) and on the CHiC cluster (right)
operate on the same zone. For the benchmark test, a variety of multi-core platforms is used. The benchmarks on the SGI Altix are executed within a partition consisting of 128 nodes each equipped with two dual-core Intel Itanium Montecito processors running at 1.6 GHz. The interconnection network is a high-speed NUMAlink 4 that offers a bidirectional bandwidth of 6.4 GByte/s per link. The Intel quad-core Xeon cluster consists of two nodes each equipped with two Intel Xeon E5345 “Clovertown” quad-core processors clocked at 2.33 GHz. An InfiniBand network with 10 GBit/s connects the nodes. The CHiC cluster includes 530 nodes consisting of two AMD Opteron 2218 dual-core processors with a clock rate of 2.6 GHz connected Figure 8. Speedups of a different execution schemes for the IRK method on the SGI Altix (left) and for the PABM method on the CHiC cluster (right)
266
Mixed Programming Models Using Parallel Tasks
Figure 9. Comparison of the execution times of a single time step of the PABM method using different mapping strategies on SGI Altix (left) and on the quad-core Xeon cluster (right)
by a 10 GBit/s InifiniBand network. First, we compare a standard data parallel version with task parallel versions based on the M-task and CM-task models. The CM-task version of the IRK and PABM methods utilizes an optimized communication scheme based on an orthogonal arrangement of the processes (cf. Figure 1). The execution times of a single time step of the IRK method using the RadauIIA7 method with s = 4stage vectors are compared for the sparse Brusselator system on 16 processor cores of the Xeon cluster in Figure 7 (left). The M-task version is not competitive due to its large communication overhead. This overhead can be
Figure 10. Performance of the LU-MZ benchmark for problem classes ‘C’ and ‘D’ on CHiC (left) and SGI Altix (right)
267
Mixed Programming Models Using Parallel Tasks
reduced significantly by the CM-task version leading to much lower runtimes. Figure 7 (right) shows the execution times of the IRK method using 960 processor cores of the CHiC cluster and the dense Schrödinger equation. Communication is less important for dense systems and therefore the differences between the program versions are smaller. Again, the lowest execution times are achieved by the CMtask program version. Figure 8 compares the achieved speedups for the IRK method on the SGI Altix (left) and for the PABM method with K = 8 stage vectors on the CHiC cluster (right). In both cases the CM-task version achieves a superior performance compared to M-task based task parallelism and pure data parallelism. Figure 9 shows the execution times of a single time step of the PABM method on the SGI Altix using 256 processor cores (left) and on the quad-core Xeon cluster using 16 processor cores (right). On both systems, task parallelism leads to better execution times because the communication within M-tasks can be restricted to subgroups of cores. The best mapping strategy is the scattered mapping because the data exchanges between M-tasks at the end of each time step can be executed within a cluster node. The performance of the LU-MZ benchmark is depicted in Figure 10 for the CHiC cluster (left) and for the SGI Altix (right). Problem classes ‘C’ with a global mesh size of 480 × 320 × 28 and ‘D’ with a global mesh size of 1632 × 1216 × 34 are used. The data parallel version of class ‘C’ can only be executed for up to 448 cores because a minimum amount of data is required for each process. For a low number of cores, pure data parallelism leads to better results because a data exchange between zones is not required. But on a high number of cores the communication within the zones becomes more important because the amount of data and, thus, the amount of computation assigned to each process becomes smaller. The node consecutive mapping leads to the best performance on both platforms. For class ‘D’ the computation to communication ratio is much higher leading to smaller differences between the program versions. The IRK, PABM and LU-MZ benchmarks prove that a mixed task and data parallel execution scheme can outperform pure data parallelism on a variety of platforms. Additional optimizations of the communication pattern as it is possible with the extended CM-task model lead to a further increase of the performance. Additionally, it has been shown that different mapping strategies can lead to significant differences in the performance on multi-core clusters. The best mapping strategy mainly depends on the communication requirements of the application, but also the communication performance of the interconnection networks of the architecture needs to be taken into account.
CONCLUSION Mixed task and data parallel execution schemes are a flexible method to exploit the computing power of up-to-date distributed memory platforms. Program development in these mixed programming models is more complex and error-prone compared to pure task or data parallel models because the organization of the processor groups and the execution of data re-distribution operations additionally have to be taken into account. Moreover, the optimal assignment of the tasks of an application to processors may depend on the target platform and therefore a complex restructuring of the application might be required when porting to another platform. Therefore, a variety of programming support to assist the application developer is available. In this article, we have discussed several of these approaches. In particular, we have considered the runtime library TLib and the coordination model TwoL. TLib supports the structuring of application programs using hierarchically organized multiprocessor tasks.
268
Mixed Programming Models Using Parallel Tasks
The library provides an easy to use interface and relieves the programmer from the processor group management. The TwoL model includes a specification language for the definition of hierarchical multiprocessor task programs. Several transformation steps are available to transform a specification of a parallel algorithm into an executable message passing program. The transformation is guided by an underlying cost model. Additionally, we have discussed the model of communicating multiprocessor tasks that is a natural extension to existing models and which supports communication between running tasks. The advantage of this model is to enable special communication patterns like orthogonal communication. The benefits of this programming model were demonstrated using solution methods for ordinary differential equations. Programming support for communicating multiprocessor tasks has been presented in form of a transformation-based compiler framework. Finally, we have presented several mapping strategies to adapt multiprocessor task applications to the hierarchical structure of recent multi-core SMP clusters. The proposed mapping strategies have been applied to example codes from numerical analysis. It was shown that the optimal mapping strategy depends on the ratio of communication within multiprocessor tasks and between tasks.
REFERENCES Aldinucci, M., Danelutto, M., & Teti, P. (2003). An advanced environment supporting structured parallel programming in Java. Future Generation Computer Systems, 19(5), 611–626. doi:10.1016/S0167739X(02)00172-3 Allen, E., Chase, D., Hallett, J., Luchangco, V., Maessen, J.-W., Ryo, S., et al. (2008). The Fortress language specification, Version 1.0. Santa Clara, CA: Sun Microsystems, Inc. Bal, H. E., & Haines, M. (1998). Approaches for integrating task and data parallelism. IEEE Concurrency, 6(3), 74–84. doi:10.1109/4434.708258 Ben Hassen, S., Bal, H. E., & Jacobs, C. J. H. (1998). A task- and data-parallel programming language based on shared objects. [TOPLAS]. ACM Transactions on Programming Languages and Systems, 20(6), 1131–1170. doi:10.1145/295656.295658 Brandes, T. (1999). Exploiting advanced task parallelism in high performance Fortran via a task library. In Euro-Par ‘99: Proceedings of the 5th International Euro-Par Conference on Parallel Processing (pp. 833–844). London: Springer-Verlag. Chamberlain, B. L., Callahan, D., & Zima, H. P. (2007). Parallel programmability and the chapel language. International Journal of High Performance Computing Applications, 21(3), 291–312. doi:10.1177/1094342007078442 Chandy, M., Foster, I., Kennedy, K., Koelbel, C., & Tseng, C.-W. (1994). Integrated support for task and data parallelism. The International Journal of Supercomputer Applications, 8(2), 80–98. Chapman, B., Haines, M., Mehrota, P., Zima, H., & van Rosendale, J. (1997). Opus: A coordination language for multidisciplinary applications. Science Progress, 6(4), 345–362.
269
Mixed Programming Models Using Parallel Tasks
Chapman, B. M., Mehrotra, P., van Rosendale, J., & Zima, H. P. (1994). A software architecture for multidisciplinary applications: integrating task and data parallelism. In CONPAR 94 - VAPP VI: Proceedings of the Third Joint International Conference on Vector and Parallel Processing (pp. 664–676). London: Springer-Verlag. Charles, P., Grothoff, C., Saraswat, V., Donawa, C., Kielstra, A., Ebcioglu, K., et al. (2005). X10: An object-oriented approach to non-uniform cluster computing. In OOPSLA ’05 Proceedings of the 20th annual ACM SIGPLAN Conference on Object Oriented Programming, Systems, Languages, and Applications (pp. 519–538). New York: ACM. Ciarpaglini, S., Folchi, L., Orlando, S., Pelagatti, S., & Perego, R. (2000). Integrating task and data parallelism with taskHPF. In H. R. Arabnia (Ed.). Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications, PDPTA 2000. Las Vegas, NV: CSREA Press. Diaz, M., Rubio, B., Soler, E., & Troya, J. M. (2002). A border-based coordination language for integrating task and data parallelism. Journal of Parallel and Distributed Computing, 62(4), 715–740. doi:10.1006/jpdc.2001.1814 Diaz, M., Rubio, B., Soler, E., & Troya, J. M. (2003). Domain interaction patterns to coordinate HPF tasks. Parallel Computing, 29(7), 925–951. doi:10.1016/S0167-8191(03)00064-4 Diaz, M., Rubio, B., Soler, E., & Troya, J. M. (2004). SBASCO: Skeleton-based scientific components. In Proceedings of the 12th Euromicro Workshop on Parallel, Distributed and Network-Based Processing (PDP 2004) (pp. 318–325). Washington, DC: IEEE Computer Society. Dorta, A. J., González, J. A., Rodriguez, C., & de Sande, F. (2003). LLC: A parallel skeletal language. Parallel Processing Letters, 13(3), 437–448. doi:10.1142/S0129626403001409 Dorta, A. J., López, P., & de Sande, F. (2006). Basic skeletons in LLC. Parallel Computing, 32(7-8), 491–506. doi:10.1016/j.parco.2006.07.001 Dümmler, J., Kunis, R., & Rünger, G. (2007a). A scheduling toolkit for multiprocessor-task programming with dependencies. In Proceedings of the 13th International Euro-Par Conference (pp. 23–32). Berlin: Springer. Dümmler, J., Kunis, R., & Rünger, G. (2007b). A comparison of scheduling algorithms for multiprocessortasks with precedence constraints. In Proceedings of the 2007 High Performance Computing & Simulation (HPCS’07) Conference (pp. 663–669). ECMS. Dümmler, J., Rauber, T., & Rünger, G. (2007). Communicating multiprocessor-tasks. In Proceedings of the 20th International Workshop on Languages and Compilers for Parallel Computing (LCPC 2007). Berlin: Springer. Dümmler, J., Rauber, T., & Rünger, G. (2008a). A transformation framework for communicating multiprocessor-tasks. In Proceedings of the 16th Euromicro International Conference on Parallel, Distributed and Network-Based Processing (PDP 2008) (pp. 64–71). New York: IEEE Computer Society.
270
Mixed Programming Models Using Parallel Tasks
Dümmler, J., Rauber, T., & Rünger, G. (2008b). Mapping algorithms for multiprocessor tasks on multicore clusters. In Proceedings of the 37th International Conference on Parallel Processing (ICPP08). New York: IEEE Computer Society. Fink, S. J. (1998). A programming model for block-structured scientific calculations on smp clusters. Doctoral thesis, University of California, San Diego, CA. Foster, I., Kohr, D. R., Krishnaiyer, R., & Choudhary, A. (1996). Double standards: Bringing task parallelism to HPF via the message passing interface. In Proceedings of the 1996 ACM/IEEE Conference on Supercomputing (pp. 36-36). New York: IEEE Computer Society. Foster, I. T., & Chandy, K. M. (1995). Fortran M: A language for modular parallel programming. Journal of Parallel and Distributed Computing, 26(1), 24–35. doi:10.1006/jpdc.1995.1044 Fox, G., Hiranandani, S., Kennedy, K., Koelbel, C., Kremer, U., Tseng, C.-W., et al. (1990). Fortran D Language Specification (No. CRPC-TR90079), Houston, TX. Grelck, C., Scholz, S.-B., & Shafarenko, A. V. (2007). Coordinating data parallel SAC programs with S-Net. In Proceedings of the 21th International Parallel and Distributed Processing Symposium (IPDPS 2007) (pp. 1–8). New York: IEEE. High Performance Fortran Forum. (1993). High performance Fortran language specification, version 1.0 (No. CRPC-TR92225). Center for Research on Parallel Computation, Rice University, Houston, TX. High Performance Fortran Forum. (1997). High performance Fortran language specification 2.0. Center for Research on Parallel Computation, Rice University, Houston, TX. Hunold, S., Rauber, T., & Rünger, G. (2004). Multilevel hierarchical matrix-matrix multiplication on clusters. In Proceedings of the 18th International Conference of Supercomputing (ICS’04) (pp. 136–145). New York: ACM. Hunold, S., Rauber, T., & Rünger, G. (2008). Combining building blocks for parallel multi-level matrix multiplication. Parallel Computing, 34(6-8), 411–426. doi:10.1016/j.parco.2008.03.003 Joisha, P. G., & Banerjee, P. (1999). PARADIGM (version 2.0): A new HPF compilation system. In IPPS ’99/SPDP ’99: Proceedings of the 13th International Symposium on Parallel Processing and the 10th Symposium on Parallel and Distributed Processing (pp. 609–615). Washington, DC: IEEE Computer Society. Kessler, C. W., & Löwe, W. (2007). A framework for performance-aware composition of explicitly parallel components. In [Jülich/Aachen, Germany: IOS Press.]. Proceedings of the International Conference ParCo, 2007, 227–234. Knuth, D. E. (1975). The art of computer programming. Volume 1: Fundamental Algorithms. Reading, MA: Addison Wesley. Kühnemann, M., Rauber, T., & Rünger, G. (2004). A source code analyzer for performance prediction. In Proceedings of IPDPS’04 Workshop on Massively Parallel Processing (WMPP’04. New York: IEEE.
271
Mixed Programming Models Using Parallel Tasks
Laure, E. (2001). OpusJava: A Java framework for distributed high performance computing. Future Generation Computer Systems, 18(2), 235–251. doi:10.1016/S0167-739X(00)00094-7 Laure, E., Mehrotra, P., & Zima, H. P. (1999). Opus: Heterogeneous computing with data parallel tasks. Parallel Processing Letters, 9(2). doi:10.1142/S0129626499000256 Merlin, J. H., Baden, S. B., Fink, S., & Chapman, B. M. (1999). Multiple data parallelism with HPF and KeLP. Future Generation Computer Systems, 15(3), 393–405. doi:10.1016/S0167-739X(98)00083-1 N’takpé. T., & Suter, F. (2006). Critical path and area based scheduling of parallel task graphs on heterogeneous platforms. In Proceedings of the Twelfth International Conference on Parallel and Distributed Systems (ICPADS) (pp. 3–10), Minneapolis, MN. N’takpé. T., Suter, F., & Casanova, H. (2007). A comparison of scheduling approaches for mixed-parallel applications on heterogeneous platforms. In 6th International Symposium on Parallel and Distributed Computing (pp. 35–42). Hagenberg, Austria: IEEE Computer Press. Orlando, S., Palmerini, P., & Perego, R. (2000). Coordinating HPF programs to mix task and data parallelism. In Proceedings of the 2000 ACM Symposium on Applied Computing (SAC’00) (pp. 240–247). New York: ACM Press. Orlando, S., & Perego, R. (1999). COLTHPF, A run-time support for the high-level co-ordination of HPF tasks. Concurrency (Chichester, England), 11(8), 407–434. doi:10.1002/(SICI)10969128(199907)11:8<407::AID-CPE435>3.0.CO;2-0 Pelagatti, S. (2003). Task and Data Parallelism in P3L. In F. A. Rabhi & S. Gorlatch (Eds.), Patterns and skeletons for parallel and distributed computing (pp.155–186). London: Springer-Verlag. Pelagatti, S., & Skillicorn, D. B. (2001). Coordinating programs in the network of tasks model. Journal of Systems Integration, 10(2), 107–126. doi:10.1023/A:1011228808844 Radulescu, A., Nicolescu, C., van Gemund, A. J. C., & Jonker, P. (2001). CPR: Mixed task and data parallel scheduling for distributed systems. In Proceedings of the 15th International Parallel and Distributed Processing Symposium (IPDPS’01) (pp. 39-46). New York: IEEE Computer Society. Radulescu, A., & van Gemund, A. J. C. (2001). A low-cost approach towards mixed task and data parallel scheduling. In Proceedings of the International Conference on Parallel Processing (ICPP’01)(pp. 69–76). New York: IEEE Computer Society. Ramaswamy, S. (1996). Simultaneous exploitation of task and data parallelism in regular scientific computations. Doctoral thesis, University of Illinois at Urbana-Champaign. Ramaswamy, S., Sapatnekar, S., & Banerjee, P. (1997). A framework for exploiting task and data parallelism on distributed memory multicomputers. IEEE Transactions on Parallel and Distributed Systems, 8(11), 1098–1116. doi:10.1109/71.642945 Ramaswamy, S., Simons, B., & Banerjee, P. (1996). Optimizations for efficient array redistribution on distributed memory multicomputers. Journal of Parallel and Distributed Computing, 38(2), 217–228. doi:10.1006/jpdc.1996.0142
272
Mixed Programming Models Using Parallel Tasks
Rauber, T., Reilein-Ruß, R., & Rünger, G. (2004a). Group-SPMD programming with orthogonal processor groups. Concurrency and Computation: Practice and Experience . Special Issue on Compilers for Parallel Computers, 16(2-3), 173–195. Rauber, T., Reilein-Ruß, R., & Rünger, G. (2004b). On compiler support for mixed task and data parallelism. In G. R. Joubert, W. E. Nagel, F. J. Peter, & W. V. Walter (Eds.), Parallel Computing: Software Technology, Algorithms, Architectures & Applications. Proceedings of 12th International Conference on Parallel Computing (ParCo’03) (pp. 23–30). New York: Elsevier. Rauber, T., & Rünger, G. (1996). The compiler TwoL for the design of parallel implementations. In Proceedings of the 1996 Conference on Parallel Architectures and Compilation Techniques(PACT’96) (pp. 292-301). Washington, DC: IEEE Computer Society. Rauber, T., & Rünger, G. (1999). Compiler support for task scheduling in hierarchical execution models. Journal of Systems Architecture, 45(6-7), 483–503. doi:10.1016/S1383-7621(98)00019-8 Rauber, T., & Rünger, G. (1999a). Parallel execution of embedded and iterated Runge-Kutta methods. Concurrency (Chichester, England), 11(7), 367–385. doi:10.1002/(SICI)1096-9128(199906)11:7<367::AIDCPE430>3.0.CO;2-G Rauber, T., & Rünger, G. (1999b). Scheduling of data parallel modules for scientific computing. In Proceedings of the 9th SIAM Conference on Parallel Processing for Scientific Computing (PPSC), SIAM(CD-ROM), San Antonio, TX. Rauber, T., & Rünger, G. (2000). A transformation approach to derive efficient parallel implementations. IEEE Transactions on Software Engineering, 26(4), 315–339. doi:10.1109/32.844492 Rauber, T., & Rünger, G. (2005). TLib - A library to support programming with hierarchical multiprocessor tasks. Journal of Parallel and Distributed Computing, 65(3), 347–360. Rauber, T., & Rünger, G. (2006). A data re-distribution library for multi-processor task programming. International Journal of Foundations of Computer Science, 17(2), 251–270. doi:10.1142/ S0129054106003814 Rauber, T., & Rünger, G. (2007). Mixed task and data parallel executions in general linear methods. Science Progress, 15(3), 137–155. Rauber, T., Rünger, G., & Wilhelm, R. (1995). Deriving optimal data distributions for group parallel numerical algorithms. In Proceedings of the Conference on Programming Models for Massively Parallel Computers (PMMP’94) (pp. 33–41). Washington, DC: IEEE Computer Society. Reilein-Ruß, R. (2005). Eine komponentenbasierte Realisierung der TwoL Spracharchitektur. PhD Thesis, TU Chemnitz, Fakultät für Informatik, Chemnitz, Germany. Sips, H. J., & van Reeuwijk, C. (2004). An integrated annotation and compilation framework for task and data parallel programming in Java. In Parallel Computing (PARCO): Software Technology, Algorithms, Architectures and Applications (pp. 111–118). New York: Elsevier. Skillicorn, D. B. (1999). The network of tasks model, (TR1999-427). Queen’s University, Kingston, Canada.
273
Mixed Programming Models Using Parallel Tasks
Subhlok, J., & Vondran, G. (1995). Optimal mapping of sequences of data parallel tasks. ACM SIGPLAN Notices, 30(8), 134–143. doi:10.1145/209937.209951 Subhlok, J., & Yang, B. (1997). A new model for integrated nested task and data parallel programming. In Proceedings of the 6th ACM SIGPLAN symposium on Principles and Practice of Parallel Programming (pp. 1–12). New York: ACM Press. Suter, F., Desprez, F., & Casanova, H. (2004). From heterogeneous task scheduling to heterogeneous mixed parallel scheduling. In Proceedings of the 10th International Euro-Par Conference (Euro-Par’04), (LNCS: Vol. 3149, pp. 230–237). Pisa, Italy: Springer. van der Houwen, P. J., & Messina, E. (1999). Parallel Adams methods. Journal of Computational and Applied Mathematics, 101(1-2), 153–165. doi:10.1016/S0377-0427(98)00214-3 van der Houwen, P. J., & Sommeijer, B. P. (1991). Iterated Runge-Kutta methods on parallel computers. SIAM Journal on Scientific and Statistical Computing, 12(5), 1000–1028. doi:10.1137/0912054 van der Wijngaart, R. F., & Jin, H. (2003). The NAS parallel benchmarks, multi-zone versions (No. NAS-03-010). NASA Ames Research Center, Sunnydale, CA. van Reeuwijk, C., Kuijlman, F., & Sips, H. J. (2003). Spar: A set of extensions to Java for scientific computation. Concurrency and Computation, 15, 277–299. doi:10.1002/cpe.659 Vanneschi, M. (2002). The programming model of ASSIST, an environment for parallel and distributed portable applications. Parallel Computing, 28(12), 1709–1732. doi:10.1016/S0167-8191(02)00188-6 Vanneschi, M., & Veraldi, L. (2007). Dynamicity in distributed applications: Issues, problems and the ASSIST approach. Parallel Computing, 33(12), 822–845. doi:10.1016/j.parco.2007.08.001 Vydyanathan, N., Krishnamoorthy, S., Sabin, G., Çatalyürek, Ü. V., Kurç, T. M., Sadayappan, P., et al. (2006a). An integrated approach for processor allocation and scheduling of mixed-parallel applications. In Proceedings of the 2006 International Conference on Parallel Processing (ICPP’06) (pp. 443–450). New York: IEEE. Vydyanathan, N., Krishnamoorthy, S., Sabin, G., Çatalyürek, Ü. V., Kurç, T. M., Sadayappan, P., et al. (2006b). Locality conscious processor allocation and scheduling for mixed parallel applications. In Proceedings of the 2006 IEEE International Conference on Cluster Computing, September 25-28, 2006, Barcelona, Spain. New York: IEEE. West, E. A., & Grimshaw, A. S. (1995). Braid: Integrating task and data parallelism. In Proceedings of the Fifth Symposium on the Frontiers of Massively Parallel Computation (Frontiers’95) (p. 211). New York: IEEE Computer Society.
KEY TERMS AND DEFINITIONS CM-Task: A CM-task is an extension of an M-task that additionally supports data exchanges with other CM-tasks during its execution.
274
Mixed Programming Models Using Parallel Tasks
Data Parallelism: Data parallel computations apply the same operation in parallel on different elements of the same set of data. M-Task: An M-task is a parallel program fragment that operates on a set of input parameters and produces a set of output parameters. The implementation of an M-task supports an execution on an arbitrary number of processors. Mapping: Mapping assigns specific physical processing units, e.g., specific cores of a multi-core SMP cluster, to tasks of an application. Mixed Parallelism: Mixed parallelism is a combination of task and data parallelism that supports the concurrent execution of independent data parallel tasks each operating on a different set of data. Scheduling: Scheduling defines an execution order of the tasks of an application and an assignment of tasks to processing units. Scheduling for mixed parallel applications additionally has to fix the number of executing processors for each data parallel task. Task Parallelism: Task parallel computations consist of a set of different tasks that operate independently on different sets of data.
275
276
Chapter 12
Programmability and Scalability on Multi-Core Architectures Jaeyoung Yi Yonsei University, Seoul, Korea Yong J. Jang Yonsei University, Seoul, Korea Doohwan Oh Yonsei University, Seoul, Korea Won W. Ro Yonsei University, Seoul, Korea
ABSTRACT In this chapter, we will describe today’s technological trends on building a multi-core based microprocessor and its programmability and scalability issues. Ever since multi-core processors have been commercialized, we have seen many different multi-core processors. However, the issues related to how to utilize the physical parallelism of cores for software execution have not been suitably addressed so far. Compared to implementing multiple identical cores on a single chip, separating an original sequential program into multiple running threads has been an even more challenging task. In this chapter, we introduce several different software programs which can be successfully ported on the future multi-core based processors and describe how they could benefit from the multi-core systems. Towards the end, the future trends in the multi-core systems are overviewed.
INTRODUCTION Intel has shipped the first dual-core processor as early as 2005 and many major processor vendors have developed dual-core or quad-core processors since then. We are now entering the new era of the multi-core processors, and practically every field in computer science or computer engineering will be affected by this strong movement. Though computing power has improved dramatically with higher clock frequencies and techniques such as superscalar, superpipelining, and VLIW (Very Large InstrucDOI: 10.4018/978-1-60566-661-7.ch012
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Programmability and Scalability on Multi-Core Architectures
tion Word), it seems that this progress will see a significant slowdown and we will have to come up with other solutions to maintain the speed of improvement we are enjoying now. There are three main reasons for the slowdown in single core performance improvement. First of all, we cannot increase the clock frequency following the Moore’s Law due to the power dissipation concerns and thermal problems. As millions of transistors are integrated onto one chip and as the clock speed goes up, the heat becomes too much to handle with current affordable cooling solutions. Secondly, the latency of processor-memory requests becomes a limiting factor, caused by the gap of speed advancements between the processor and the memory. Indeed, this becomes a major bottleneck for overall computing performance. Lastly, it is known that ILP (instruction-level parallelism) from a single thread almost reaches its limit in the current microprocessor architectures and compiler techniques. Therefore, we can see that the next path to take is the multi-core approach; instead of trying to improve the performance of single thread execution, we should partition applications into multiple threads that can run in parallel on prevailing multi-core systems. In this chapter, we are going to look at recent researches on multi-core architectures and how to fully utilize the multi-core systems. In the next section, we look at hardware designs and characteristics of the multi-core architectures. In Section 3, we explain software programming skills to exploit parallelism in two specific applications which are network coding and Intrusion Detection Systems (IDS). In Section 4, we touch on the programmability and scalability issues to use multi-core systems for video applications, and in Section 5, we conclude the chapter with forecasting on future multi-core systems.
BACKGROUND STUDY: HARDWARE DESIGNS OF MULTI-CORE ARCHITECTURE In this section, the general hardware architecture of current multi-core processors is surveyed as background study. We first describe the basic method to build multi-core processors and then describe the memory hierarchy design issues for multi-core system.
Multi-Core Processor Architecture: Homogeneous or Heterogeneous In a simplest way to design multi-core processors, we can just imagine to arrange multiple processing units (so called cores) on a single chip. In theory, this might be a good way to boost performance by providing parallelism through more processors. However, in reality, multi-cores do not always promise the performance enhancement in software execution (Hill & Marty, 2008) . In fact, it could cause opposite results due to some communication restrictions and memory sharing problems. Therefore, hardware designers of multi-core based processors have to research various methods of multi-core structure and simultaneously find effective algorithm of data sharing to boost performance and efficiency of processing. According to an architect for a specific design, the internal architecture of each core can vary. Actually, the core can be either heterogeneous or homogeneous. In Figure 1, we show the two ways to build a multi-core processor. The left-side two diagrams show multi-core processor from Intel and AMD which can be classified as “homogeneous multi-core processors”. As the name implies, these models integrate identical cores on to a single chip. Yorkfield from Intel is a quad-core CPU that integrates two dual-core CPUs onto a single die. Phenome from AMD consists of four cores that have identical architecture and shared L3 cache on a single chip.
277
Programmability and Scalability on Multi-Core Architectures
Figure 1. Two-ways to build a multi-core processor
On the other hand, the diagram on the right side, Cell Broadband Engine is a heterogeneous processor. The processor is originally developed as a co-project of Sony, IBM, and Toshiba. There are one functional core and eight synergistic processor elements performing data-intensive processing (Gschwind, Hofstee, Flachs, Hopkins, Watambe & Yamazaki, 2006) . Today, most of manufacturers have followed homogeneous type for a certain reason; they have just preferred to utilize the previously developed design for a single core processor. In fact, it might provide the balance of computing ability between high throughput and good single-thread performance. In addition, simple re-use of micro-architecture provides great portability and scalability for previously provided applications and legacy codes. It is an easy way to build multi-core architectures as we only need to add multiple cores to a single-chip processor. In spite of these advantages of homogeneous structure, most processor architects expect that heterogeneous multi-core processors such as the Cell processor would perform more powerfully and effectively than homogeneous ones (Pericas, Cristal, Cazorla, Gonzalez, Jimenez & Valero, 2007)(Kumar, Tullsen & Jouppi, 2006). The reason is that the heterogeneous type can be designed to match each application to the specific multi-core processor; it is a better approach to meet high performance. This approach allows us to design more efficient power consumption architecture in smaller chip die area (Kowaliski, n.d.) . Another reason is that the number of data to process is being enlarged more sharply than the number of instructions with development of the digital technology. In order to process numerous data, it is needless to say that heterogeneous one is much more suitable than homogeneous one. One of examples for heterogeneous multi-core architecture is implemented with Graphics Processing Units. The expectation to large amount of data processing would affect that GPU (Graphics Processing Unit) is developed as a general purpose processing unit named GP-GPU (general purpose-GPU). Most companies that make processing units such as GPU, DSP, and CPU also expect GP-GPU should make strong transition into CPU’s market (Kowaliski, n.d.) .
278
Programmability and Scalability on Multi-Core Architectures
Figure 2. Single-core and multi-core processors various multi-core processors
The example of this trend is shown at major processor companies; AMD has acquired ATI that is a famous graphics processing unit maker. Also, it seems that Intel has interested in this trend as developing the GPU architecture named Larabee. In addition, NVIDIA, one of the most famous GPU makers, tries to develop general purpose processing unit based on the traditional graphics processing unit.
Memory Hierarchy Design Main memory latency becomes a major delay in modern computer systems either in single-core systems or multi-core systems. Indeed, the architectural design for memory system is very important for the performance of multi-core processors. Especially, cache has one more important duty in the multi-core systems; the coherency protocol. The shared cache in multi-core processor has to observe the change of data and notify each cores about it. In Figure 2, we show various multi-core processor models with different cache designs. There are no cache sharing in the single core processor and the simple dual-core processor. On the other hand, the shared L2 cache dual-core processors integrate a shared L2 cache; the cache coherence protocol must be adequately designed in order to use the shared L2 cache in a proper way. One of the most important aspects in designing multi-core processors is memory hierarchy and data sharing techniques among different cores. Much like the traditional shared memory architectures, the data between running threads on different cores are passed through the shared memory. To this point, the cache design plays an important role and becomes a major issue in designing multi-core processors.
279
Programmability and Scalability on Multi-Core Architectures
As a consequence, the performance of today’s multi-core systems remarkably depends on the size of cache, the cache hierarchy, and shared cache architecture (Schirrmeister, 2007). In fact, the performance would be improved on the single core architecture as the size of cache becomes larger. However, the advantages of a large-sized cache become less effective in multi-core processors due to the data sharing operation and coherence protocol (Kowaliski, n.d.) . Indeed, the structures of cache hierarchy and coherence protocols are considered as more important than the size in multi-core processors. For that reason, research about cache structure in a multi-core processor is being studied by various sides; many different structures have been proposed and developed in order to achieve improvement of performance. The design of multi-core is more complicated than the design of single core, due to data sharing between cores and grouping of cores. The simple combination of single cores without any consideration for grouping does not perform well; the main reason is that an original single core has not been designed considering any parallelism. However, to have a better design as a multi-core processor, we must design it fully considering the parallel execution of software and communications between cores. Therefore, the special design and technique should be added on top of simple arrangement of cores. This special design and technique could be related to the basic core architectures or a combination structure of cores architectures. There are many ways to extract the potential parallelism by providing a better hardware platform. To find the best way, we must design the hardware platform based on execution of software parallelism.
ExPLOITING SOFTWARE PARALLELISM ON A MULTI-CORE SYSTEM In this section, we will look into three approaches to exploit software parallelism using a multi-core system. The first application described is network application. After that, we will present an algorithm development of intrusion detection system as a multi-core application.
Network Coding on Multi-Core Systems Network coding is a method that increases the network transmission rate while increasing reliability and security. It does this by performing coding operations on packets not only in the source nodes but also at intermediate nodes throughout the network topology between the source and receivers. The idea was first proposed by Ahlswede et al (Akenine-Moller, 2002), who showed the usefulness of network coding in multicast networks. It was further researched by others, who showed that simple linear structures could be used for the implementation of network coding (Gschwind, et al., 2006), and going further, that a random combination of the linear codes could be used in decoding (Fernando, Harris, Wloka & Zeller, 2004) . In Figure 3, we show a communication network, a directed graph where the edges represent pathways for information (Li, Yeung & Cai, 2003) . At the source S, information is generated and then multicasted to other nodes in the network. Here, every node can pass on whatever information it has received. Now, suppose you generate data bits a and b at source S. We want to send the data to both node D and node E. By the Max-flow min-cut theorem (Wikkipedia, Gauss-Jordan elimination), we can calculate the maximum flow, that is, the maximum amount of information we can transmit through this network. We cannot achieve this maximum rate by just routing, and that is where network coding comes in.
280
Programmability and Scalability on Multi-Core Architectures
Figure 3. A communication networks for network coding
We first send data a through path SA, AC, AD, and data b through SB, BC, BE. With the routing scheme, we can only send a copy of either a or b but not both, from C down to the path CZ. Suppose we send data a through CZ. Then node D would receive data a twice, once from A and once from Z, and would not get data b. Sending data b instead would also raise the same problem for node E. Therefore, we could say that routing is insufficient as it cannot send both data a and data b to both destinations node D and E simultaneously. Using network coding, on the other hand, we could encode the data a and b received in node C and send down the encoded version to CZ. Say we use bitwise xor for encoding. Then, data a and b are encoded to ‘a xor b’. The encoded data is sent along on the path CZ, ZD, and ZE. Node D receives data a and ‘a xor b’, so it can decode and get data b from it. It is the same for node E, where it receives data b and ‘a xor b’, extracting data a by decoding. By looking at this example, it is clear that network coding has a huge advantage over simple routing. Network coding enables us to multicast two bits per unit time from the source down to the destinations, which you cannot achieve through routing. Now, with this high transmission capacity, another factor in performance is the encoding/decoding speed. It has to be fast enough not to be a performance bottleneck, and in today’s multi-core environment, fast encoding/decoding can be achieved by exploiting parallelism. In this case, we shall pick the method of linear encoding and random linear decoding mentioned earlier, and see how we can parallelize it. First, we will take a look at the big picture of encoding and decoding, then the specific algorithm and parallelization. Let us assume that an application generates a stream of equal sized frames. Organize these frames into blocks, which contain a number of consecutive frames. Suppose the frames are numbered, then b(blockID, blockSize) denotes a block which holds frame(blockID) to frame(blockID+blockSize-1). A coded packet c(blockID,blockSIze) is a linear combinations of the frames within b(blockID,blockSIze). That is c(blockID ,blockSize ) = å k =1 ek p(k + blockSize - 1) , where pk is an application frame and the coefficient ek is a certain element in a chosen finite field F. Every arithmetic operation will be over field F. (Figure 4) A blockSize number of application frames is needed to make a coded packet, so a source node waits blockSize
281
Programmability and Scalability on Multi-Core Architectures
Figure 4. Blocks and coded packets
for enough frames to accumulate before starting encoding. The encoded packet will be broadcasted to other destination nodes along with the coefficient vector stored in the header. Nodes in the path to the destinations nodes will re-encode the coded packets and send them along. When the coded packet reaches a destination node it will get stored it in the memory. For the destination node to decode the package into the original data block with blockSize frames, it needs to get blockSize coded packets with independent coefficient vectors. T T T T T T T ] , and P = [pblockID ...pblockID +blockSize-1 ] , where If we denote E = [e1 ...eblockSize ] , C T = [c1T ...cblockSize superscript T stand for the transpose operation. As the coded packet was calculated as C = EP, we can decode C into the original block P in the destination nodes with the formula P=E-1C. Note that the matrix E needs to be convertible, so all coefficient vectors ek’s must be independent with each other. The pseudocode for the encoding algorithm is given in Figure 5, and more easily represented in Figure 4. It is basically a matrix operation. We can parallelize this operation to run in multiple threads, and depending on how we divide it the speedup could be zero to twofold. For instance, suppose you divide the work in each row * column multiplication operation in Figure 5. The operation would calculate a1 * b1 + a2 * b2 + + a 8 * b8 , so you can make a few threads that does each multiplication an*bn and add up all the results of the threads in the end. It seems possible when you only think about it in the algorithm level, but the problem is that you cannot store results simultaneously in the memory. Race conditions could occur, so you have to add locks to the critical section to avoid collision. However, these locks mean that the threads cannot run in parallel; each thread has to wait its turn to use the lock. Therefore, even if you can do the multiplication in separate cores simultaneously, the memory store operation will become a bottleneck and sequentialize the whole process, hindering the speedup that can be achieved in multi-core environment. (Figure 6)
282
Programmability and Scalability on Multi-Core Architectures
Figure 5. Encoding algorithm
Figure 6. Encoding process
On the other hand, suppose you divide the work by assigning each whole row * column multiplication on different threads instead of breaking down each operation on threads, as in Figure 7. This way the process is divided into chunks so that memory storage is not a problem. Inside each chunk the operations store the temporary results in the same memory cell, but since it is sequential inside each thread it is OK. If you look at each different chunk, they store all results in different memory cells, avoiding collision and thus suitable to run in parallel. The specific description of the algorithm is as follows. As in Figure 7, we can parallelize the encoding algorithm by using threads to divide the workload. In Figure 6, a single thread does vector multiplication e1 ∙ b(1,8), e2 ∙ b(1,8), …, e8 ∙ b(1,8) to get the coded packets c1, c2, …,c8 sequentially, one at a time. In the parallelized version, we split the work into 4
Figure 7. Parallelized encoding algorithm
283
Programmability and Scalability on Multi-Core Architectures
Figure 8. Parallelized encoding process
independent parts, each running on a different thread. Thus, if the processor has more than 4 cores, we can get the coded packets c1 and c5 computed in the first core, c2 and c6 in the second, and so on. This is shown in Figure 8. Note that coded packets in the same color are calculated in the same thread. This parallelization means we get a fourfold throughput in the encoding process, excluding the time it takes to manage the threads. Figure 9. After the blocks are encoded into coded packets, they are sent to the destination node. At every node on the way to the destination, the packets go through a re-encoding process. The re-encoding process is basically the same as the encoding process, where the coded packet gets encoded once more with a randomly selected re-encoding vector. The newly coded packet c´(blockID ,blockSize ) = å k =1
blockSize
Figure 9. Re-encoding process
284
e´k ck is sent
Programmability and Scalability on Multi-Core Architectures
Figure 10. Decoding algorithm in a single-core system
along with the combined coefficient vector e´= å k =1 e´k ek . This re-encoding process can therefore be parallelized similarly, with multiple threads doing the calculations of matrix multiplication. After going through the re-encoding process in every node it passes, a coded packet along with the corresponding coefficient vector finally reaches the destination(s). The destination node waits until it receives enough of these coded packets to decode, which would be the blockSize supposing that all coefficient vectors are independent. The following process after receiving all needed packets is decoding; reconstructing the original data from the coded packets, and this is another place we could upgrade the performance in a multi-core system. If you arrange the coded blocks as a matrix, we can calculate the inverse matrix and then the original block using the Gauss-Jordan algorithm (Wikkipedia, Gauss-Jordan elimination). In a single-core machine without using threads, this process is purely sequential, as in Figure 10. However, in a multi-core environment, we can speed this process up by dividing the work into several threads which would run on separate cores in parallel. The aim of the decoding process is to transform the coefficient matrix to its reduced row echelon form with basic row operations. For each i’th vector in the coefficient matrix, the first step is to divide the whole vector by the value of the basis coordinate, say val, to make the basis coordinate 1. Then the second step is for rows above, subtract (i’th vector) * val to make the value of column i 0. For rows below, divide the vector by val and then subtract the current_vector. Each loop of this will set column i as 0, except for the i’th row. After going through every vector like this, we will get the identity matrix. Apply the same operations in the reduction process to an identity matrix, and it will reveal the inverse matrix with which we can just multiply with the coded packets to get the original blocks. Now the parallelization part here is simple. In the second step of the above algorithm, each row operation is independent with one another with no race conditions. Thus we can part the row operations into small groups to run concurrently on separate threads. This part of the algorithm corresponds to line 5-14 in the pseudocode of Figure 10, and simply making multiple threads to execute this part will do the job. See Figure 11. We have looked at the encoding/decoding process used in network coding, and have parallelized blockSize
285
Programmability and Scalability on Multi-Core Architectures
Figure 11. Parallelized decoding algorithm – I’th basis operation
it into multiple threads. As you can see, there are several problems to think of before letting multiple threads divide up the job, such as race conditions, critical regions, locks, and etc. The hard part is that present compilers do not catch these errors; you are on your own on that. Race conditions are especially hard to manage, as once you let an error like that get in it could be hard to detect. It is possible that a problem would just pop out after years of safe use of the program. It could lead to a critical mistake if hidden in medical equipment or space ships or so on. Thus, as it is with all software codes, check and double check the algorithm, and execute sufficient testing before declaring it safe to use.
Implementing Intrusion Detection System on Multi-Core Architecture Ever since the Internet service has been introduced, it has been a major method for people to communicate to each other and collect useful information from the world. Although this provides a lot of convenience to everyday life, it also contains some serious threats in a point that it may expose personal privacy. Hence the necessity of Internet security has been emphasized in order to protect personal information from the world. Moreover, ubiquitous computing will be actively developed and widely adopted in the near future; this trend will require more advanced Internet service as a backbone platform to implement successful ubiquitous computing environment. In this section, we will discuss parallel intrusion detection algorithms designed for multi-core systems.
Overview of IDS (Intrusion Detection System) Among the network security products, Intrusion Detection System (IDS) is a leading network security solution in the market. The IDS systems can be divided into two groups: the host-based IDS and the network-based IDS. Since we are interested in parallel implementation of IDS applications, the networkbased IDS will be the main target of our research. One of the main advantages of the network-based IDS is that it can support a large scale network. In addition, it is also able to detect the host server before being attacked. However there are two major problems of the network-based IDS: the packet filtering problem and the classification problem based on string matching (Akenine-Moller, 2002). The former has been improved by several previous studies
286
Programmability and Scalability on Multi-Core Architectures
Figure 12. Multi-thread test
however the latter still needs to be studied more. Boyer-Moore’s algorithm is the most well known algorithm among String matching. The algorithm is a general purpose string matching algorithm; it scans and compares the string to be matched the input string starting from the rightmost character of the string (Li, Yeung & Cai, 2003) . The weakness of string matching is that all data must be scanned. In the scanning process there are large power distribution and slowing down of performance speed (Chen, & Lee, 1999) . Therefore, this weakness should be improved. Pattern matching is the most important part in the network based IDS. However, it always requires many calculations and even worse; the number of attacking patterns is increasing day by day. Pattern matching should be able to manage patterns efficiently with various lengths, capitals and small letters, and several ordered letters at the same time. Therefore, it would be efficient to have multi-pattern matching in network based IDS to manage packets coming in at high speed (Ni, Lin, Chen & Ungsunan, 2007) . Figure 12 shows data comparing Q6600 (single-core) and E2140 (multi-core) of Intel. It is possible to improve the efficiency up to 40% by using multi-threads in virus checking. This means that the large parts of the network security can be improved by being parallelized. However, the present network security research is focused on mathematical approach, data communication, and data processing. Thus, the network security method should be more efficiently implemented by using multi-core based systems.
Parallelization of Intrusion Detection System The future computer system will be designed based on multi-core. This trend will also be applied in IDS. However, most of the research related to IDS is being studied in single-core and software. As mentioned before, several parts in IDS can be parallelized. In fact, pattern matching algorithm is an orderly process so it takes a long time (Ni, et al., 2007) . It can be solved by exploiting parallelism in the pattern matching algorithm. Figure 13 and Table 1 show the structure of the pattern matching and order of execution, respectively (Ni, et al., 2007) . As it is shown in Figure 13, the IDS scan the patterns through the pattern matching. The scanned patterns are decided in the CPU whether or not it is an attacking pattern. This process takes a long time because all patterns need to be scanned. The process until now has performed orderly. However the patterns can be divided in to several blocks because they are independent to one another.
287
Programmability and Scalability on Multi-Core Architectures
Figure 13. Structure of parallel pattern matching
Because of these characteristics, blocks can be allocated to several cores in the multi-core environment (Kowaliski, n.d.) . Each block is divided into several threads and those threads enter each allocated core. Through this, the process of pattern matching in the multi-core gets high processing speed.
GPU DEVELOPMENT ON MULTI-CORE SYSTEM Parallel computing and data-parallel programming environments provide us a high performance in a computer system. Especially, it becomes a crucial feature in the graphics processors because nearly 10, 000 data elements need to be handled at a given time (Boyd, 2008) . As a result, the graphics processor has become one of the target applications to utilize multi-core system. The large-scale 3D graphic applications have created many-cores GPUs and a large number of CPUs. Indeed many-core CPUs need a new software paradigm which can easily exploit software parallelism. To reflect this trend, NVIDIA have announced CUDA in 2007 which is a parallel programming language. The CUDA is available in multi-core system that has a shared-memory parallel processing
Table 1. Order of pattern matching 1
Fetch the patterns in the network interface
2
Scan the pattern and send to L2 cache
3
Pattern saved in the shared L2 cache
4
Several blocked-patterns input to each CPU
5
Patterns saved in L1 cache in CPU
6
Check the patterns whether it is attacking pattern or not
288
Programmability and Scalability on Multi-Core Architectures
Figure 14. 3D graphics system architecture
architectures (Nickolls, Buck & Garland, 2007) . In the graphic market, the many-core GPUs are rapidly developed because graphic processing includes many calculations. Generally, the development of the graphic market requires 3D graphic technology. 3D graphic technology should be changed because it needs high processing power. As a result, power distribution in 3D graphic technology needs to use multi-cores in order to reduce the power consumption. Moore’s law says there are more transistors on one die so more cores can be integrated. Today’s GPUs have been improved to the GPGPUs (General-Purpose computation on GPUs) (Nickolls, et al., 2007) . This leads to the strong result of the improvement in the speed.
Background of 3D Graphics Processing and GPU Generally the process of 3D Graphics is divided into three stages: application stage, geometry stage, and rasterization stage (Chen, & Lee, 1999) . The stage is shown in Figure 14. The above figure explains the three stages of the process of 3D Graphics. The first stage is the application stage. This stage is processed in the CPU and manages the user input, calculates the physical 3D object data, and also provides vertex data - such as plots, lines, triangle or polygon. The second stage is the geometry stage. In this stage, the vertex data is received from application stage and the geometry convergence is calculated (it involves the multiplication of vector) and color bit – such as clipping, lighting and coordinate transformation. The last stage is the rasterization stage; it maps the previously saved texture in the geometry stage and some effect. In addition, it also saves the final result in the frame buffer. Most of the 3D graphics chips (GPU) focus on accelerating the rasterization stage and leave the geometry processing to host CPU because the geometry processing demands lots of floating-point operations which cannot be easily handled (Chen, & Lee, 1999) . To achieve real-time 3D graphics performance, we focus more on the rasterization stage. The GPU is the most heavily used processor in the graphics field. It has shown rapid improvement in
289
Programmability and Scalability on Multi-Core Architectures
Figure 15. A modern GPU
the recent 10 years, and this has supported the increase of the capacity of the computer. In detail, GPU gives solution to rendering and parallel data. Figure 15 below describes the simplification of modern GPU (Boyd, 2008) . Parallelizing the GPU with CPU has solved the problem of data processing that causes performance bottleneck. However, this could not solve the numerous data of graphic processes. Therefore, the private used hardware (GPU) has been designed to solve the previous problem. The main core of the GPU is the shader. The shader controls the calculation of vertex or pixel data which is mainly focused on the calculation of the graphics data (Boyd, 2008) . Furthermore, a unified parallel shader has been designed to solve the I/O problems and to improve the capacity of the shader.
Parallelization of 3D Graphic Processing The whole process of the 3D graphics processing was operated in a CPU. However, there is a problem that loads of CPU gets bigger due to the high processing of the calculation (Fernando, et al., 2004) . As a result, there is a GPU (Graphics + CPU) that can separate geometry state and rasterization state to one core. The shader used in GPU is specialized processor that can accelerate API (Application Program Interface). Meanwhile, the user can receive the technical program from the 3D graphic program or other hardware block in GPU. The technical program involves the vertex and pixel data in the 3D graphic calculation process that is independent or similar calculation. So, the GPU has parallelized vertex and pixel shader. Also, inside of shader, there is a parallelized structure to improve the capability. The current trend is to integrate shaders in GPU to improve the use of shader. Integrated shaders do not have the distinction between vertex shader and pixel shader. The small shaders with the same structure together become one big component. One big shader operates efficiently because the inner small shaders are operating in parallelization. This can operate to vertex shader and pixel shader depends on the cases. Because the 3D graphics API is being programmed in the pipeline, it is possible to calculate
290
Programmability and Scalability on Multi-Core Architectures
Figure 16. GPU using parallelized shader
independently even the vertex shader and pixel shader are integrated. Parallelized integrated-shader can solve the problem of calculation being convergent and save hardware resources. Moreover, it uses the same instruction set so that the shader programming becomes easier. Figure 16 shows the inner structure of GPU where the parallelized integrate-shader is used. A parallelized shader is a homogeneous multiprocessor that has several small shaders with the same structures. Each parallelized shader is designed to accelerate the calculation of vertex or pixel in 3D programs. Even though the GPU is a processor core which is specified from the data parallel, there is a problem in using it as general purpose. However it is inefficient to be used only to process graphics. As a result, the GPGPU has been developed for general purpose of numeric value calculation. Furthermore, the two leading companies of the graphic market, NVIDIA and AMD have developed general purpose parallel programming tools. Those are CUDA (Compute Unified Device Architecture) from NVIDIA and CTM (Close to the Metal) from AMD. For example, set NVIDIA’s GPGPU to computer and install the CUDA software. This can increase the speed in the programs with many floating point calculations such as graphics. CUDA uses parallel data cache in between ALU and memory to perform the threadunit parallel process by using several ALUs. Roughly speaking, several clusters of desktop PC can be efficient as the super computer.
CONCLUSION Today, most of processor manufacturers are interested in multi-core architectures and release various multi-core products. We expect this trend would last for the next couple of years due to the following three aspects. First of all, the clock speed is no longer a major issue of processor design. This is due to the fact that as increased the clock speed, the leakage current on a chip also becomes high, so the
291
Programmability and Scalability on Multi-Core Architectures
dramatic increase of power consumption is caused and processor temperature goes high. Therefore, the higher clock frequency is no longer useful factor and the new implementation technique such as multicore architecture is required to elevate performance of processors. The second fact is that manufacturers can integrate more and more transistors onto a single chip. Since the number of transistors per chip has increased continually, the trend of multi-core processor that integrates two or more processing cores onto a single chip becomes realistic in computer technology (Hayes, 2007) . Thirdly, the market need is also the one factor that brings up the trend. Most computer users want to perform multiple tasks on their desktop machine, concurrently such as listening music, playing games, watching television, internet surfing, and so on. Therefore, the needs of computer users encourage processor makers to obtain the performance improvement through parallelism or processing cores. In this chapter, we have provided several software applications which can be used efficiently in multi-core processors.
REFERENCES Akenine-Moller, T., & Haines, E., (2002, July). Real-time rendering (2nd Ed.). Wellesley, MA: A. K. Peters Publishing Company. Aldwairi, M., Conte, T., & Franzon, P., (2005) Configurable string matching hardware for speeding up intrusion detection. ACM SIGARCH Computer Architecture News, 33(1). Alshwede, R., Cai, N, Li, S.-Y. R., & Yeung, R. W. (2000). Network information flow: Single Source. IEEE Transactions on information theory, (submitted for publication). Boyd, C. (2008, March/April). Data-parallel computing. ACM Queue; Tomorrow’s Computing Today, 6(2). doi:10.1145/1365490.1365499 Boyer, R., & Moore, J. (1977). A fast string searching algorithm. Communications of the ACM, 20(10), 762–777. doi:10.1145/359842.359859 Chen, C.-H., & Lee, C.-Y. (1999). A cost effective lighting processor for 3D graphics application. Proceedings of International Conference on Image Processing, 2, 792–796. Dharmapurikar, S., & Lockwood, J. (2006, October). Fast and Scalable Pattern Matching for Network Intrusion Detection Systems. Communication of the IEEE Journal, 24(10). Femando, R., Harris, M., Wloka, M., & Zeller, C. (2004). Programming graphics hardware. In Tutorial on EUROGRAPHICS. NVIDIA Corporation. Gschwind, M., Hofstee, H.P., Flachs, B., Hopkins M., Watambe, Y., & Yamazaki, T., (2006). Synergistic Processing in Cell’s Multicore Architecture. IEEE Computer Society, 0272-1732/06. Hammond, L., Nayfeh, B.A., & Olukotun, K. (1997, September). A Single-Chip Multiprocessor. IEEE Computer, September, 30(9), 79-85 Hayes, B. (2007). Computing in a parallel universe. American Scientist, ▪▪▪, 95. Hennessy, J.L., & Patterson, D.A., (n.d.). Computer Architecture – A Quantitative Approach (4th Ed).
292
Programmability and Scalability on Multi-Core Architectures
Hill, M. D., & Marty, M. R. (2008, July). Amdahl’s Law in the Multicore Era. HPCA 2008, IEEE 14th International Symposium (pp.187). Ho, T., Medard, M., Koetter, R., Karger, D. R., Effros, M., Shi, J., & Leong, B. (2006, October). A random linear network coding approach to multicast. IEEE Transactions on Information Theory, 52(10). doi:10.1109/TIT.2006.881746 Koetter, R., & Medard, M. (2003, October). An algebraic approach to network coding. IEEE/ACM Transactions on Networking (TON), 11(5), 782 – 795. Kowaliski, C. (2008). NVIDIA CEO talks down CPU-GPU hybrids, Larrabee. The Tech Report, April 11th. Retrieved from http://techreport.com/discussions.x/14538 Kumar, R., Tullsen, D. M., & Jouppi, N. P. (2006). Core Architecture Optimization for Heterogeneous Chip Multiprocessors. In Proceedings of the 15th International Conference on Parallel Architecture and Compilation Techniques (pact 2006) (pp. 23-32). Kumary, R. Tullsen D.M., Ranganathan, P., Jouppi, N.P., & Farkas, K.I., (2004). Single-ISA Heterogeneous Multi-Core Architecture for Multithreaded Workload Performance. In Proceedings of the 31st International Symposium on Computer Architecture (ISCA’04), June, 2004. Kwok, T. T.-O., & Kwok, Y.-K. (2007). Design and Evaluation of Parallel String Matching Algorithms for Network Intrusion Detection Systems (NPC 2007), (LNCS 4672, pp. 344-353). Berlin: Springer. Li, S.-Y. R., Yeung, R. W., & Cai, N. (2003, Feb.). Linear network coding. IEEE Transactions on Information Theory, 49(2), 371–381. doi:10.1109/TIT.2002.807285 Ni, J., & Lin, C. Chen, Z., & Ungsunan, P. (2007, September). A Fast Multi-pattern Matching Algorithm for Deep Packet Inspection on a Network Processor. In Proceedings of International Conference on Parallel Processing (ICPP 2007)(p.16). Nickolls, J., Buck. I, & Garland, M., (2008). Scalable Parallel Programming with CUPA. ACM QUEUE, March/April, 6(2), 40-53 Olukotun, K., & Hammond, L., (September 2005). The Future of Microprocessors. ACM Queue, September, 3(7), 26-29 Patterson, D.A., & Hennessy, J.L. Computer Organization and Design (3rd Ed.). Paxson, V., & Sommer, R. (2007). An Architecture Exploiting Multi-Core Processors to Parallelize Network Intrusion Prevention. In . Proceedings of IEEE Sarnoff Symposium, 3(7), 26–29. Pericas, M., Cristal, A., Cazorla, F. J., Gonzalez, R., Jimenez, D. A., & Valero, M. (2007). A Flexible Heterogeneous Multi-Core Architecture. In Proceedings of the 16th International Conference on Parallel Architecture and Compilation Techniques, (pp. 13 -24). Schirrmeister, F. (2007). Multi-core Processors: Fundamentals, Trends, and Challenges, Embedded Systems Conference, (pp. 6-15). Shen, J. P., & Lipasti, M. (2004). Modern Processor Design: Fundamentals of Superscalar Processors (1st Ed.).
293
Programmability and Scalability on Multi-Core Architectures
Wikipdedia, Gauss-Jordan elimination. Retrieved from http://en.wikipedia.org/wiki/Gauss-Jordan_elimination Wikipedia, Max-flow min-cut theorem. Retrieved from http://en.wikipedia.org/wiki/Max-flow_mincut_theorem
KEY TERMS AND DEFINITIONS Cache Coherency: Cache coherence is a method of managing conflicts and maintain consistency between cache and memory. Compiler: A compiler is a set of programs that translates text written in a computer language (the source language) into an another computer language (the target language). Instruction-Level Parallelism (ILP): ILP is a measure of how many of the instructions in a computer program can be computed simultaneously. Multi-Core: Multi-core are multi-core architectures with a high number of cores. Multiprocessor: Multiprocessor is a single computer system that has two or more processors. Parallelism: Parallelism is a method of computation in which many calculations are carried out simultaneously. Thread-Level Parallelism (TLP): TLP is a form of executing threads across different parallel computing nodes
294
295
Chapter 13
Assembling of Parallel Programs for Large Scale Numerical Modeling V. E. Malyshkin Russian Academy of Sciences, Russia
ABSTRACT The main ideas of the Assembly Technology (AT) in its application to parallel implementation of large scale realistic numerical models on a rectangular mesh are considered and demonstrated by the parallelization (fragmentation) of the Particle-In-Cell method (PIC) application to solution of the problem of energy exchange in plasma cloud. The implementation of the numerical models with the assembly technology is based on the construction of a fragmented parallel program. Assembling of a numerical simulation program under AT provides automatically different useful dynamic properties of the target program including dynamic load balance on the basis of the fragments migration from overloaded into underloaded processor elements of a multicomputer. Parallel program assembling approach also can be considered as combination and adaptation for parallel programming of the well known modular programming and domain decomposition techniques and supported by the system software for fragmented programs assembling.
INTRODUCTION Parallel implementation of realistic numerical models, using direct numerical modeling of a physical phenomenon on the basis of description of the phenomenon behaviour in the local area, usually requires high performance computations. However the algorithms of these models based on the regular data structures (like rectangular mesh) are also remarkable for irregularity and even dynamically changing irregularity of the data structure (adoptive mesh, variable time step, particles, etc.). For example, in the PIC method the test particles are in the bottom of such an irregularity. Hence, these models are very DOI: 10.4018/978-1-60566-661-7.ch013
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Assembling of Parallel Programs for Large Scale Numerical Modeling
difficult for effective parallelization and high performance implementation with conventional programming languages and systems. The Assembly Technology (AT) (Kraeva & Malyshkin, 1997), (Kraeva & Malyshkin, 1999), (Valkovskii, Malyskin, 1988) has been especially created in order to support the development of fragmented parallel programs for multicomputers. Fragmentation and dynamic load balancing are the key features of programming and program execution under AT. The application of the AT to implementation of the large scale numerical models is demonstrated on the example of parallel implementation of the PIC method (Berezin & Vshivkov, 1980), (Hockney & Eastwood, 1981), (Kraeva & Malyshkin, 2001) application to solution of the problem of energy exchange into plasma cloud. Actually AT integrates such well known programming techniques as modular programming and domain decomposition in order to provide suitable technology for the development of parallel programs implementing large scale numerical models. AT supports exactly the process of the whole program assembling out of atomic fragments of computation. The process of new knowledge extraction consisted of two major components. First, new fact is found in real physical (chemical, …) experiments. After that a theory is constructed that should explain new fact and predict unknown facts. The theory serves to the science until some new not explainable fact is found. This is long time and resources consumable process. Real experiments are often very expensive, original equipment for such experiments are prepared long time, and go on. Now the third component is added to scientific process. Numerical simulation of the natural phenomena on supercomputers is now used in order to test the developed theory in numerical experiments, not in real physical experiments. Also such numerical experiments often help to form the new real experiment if necessary. Sometimes the parameters of a physical system can not be measured, for example, the processes in plasma or inside the sun. In these cases only numerical simulation can find some arguments in order to support or to reject the theory. In comparison to real experiments, numerical experiments consume far less resources and can be organized very quickly. Therefore, the investigations of the phenomenon can be done more quickly and the phenomenon can be studied more carefully in numerous experiments. It is no wonder that the modern supercomputers are mostly loaded by the large scale numerical simulation (Kedrinskii, Vshivkov, Dudnikov, Shokin & Lazareva, 2004), (Kuksheva, Malyshkin, Nikitin, Snytnikov, Snytnikov, & Vshivkov, 2005). Unfortunately, the development of parallel programs is very difficult problem. Earlier, sequential programming languages and systems provided for numerical mathematicians the possibility to program their numerical models more or less well without any assistance from the professional programmers. It was their “private technology” (Malyshkin, 2006) of programming. Now another situation is. Development of parallel programs is far more difficult and labor consumed work. Additionally, parallel programs are very sensible to any errors, to any not optimal design decisions and/or inefficiency in programming. As result numerical mathematicians are now unable to develop parallel programs implementing their numerical models without assistance from the professional programmers. The technology of parallel programs of numerical modeling assembling out of ready made atomic fragments is suggested as “private technology” of programming for numerical mathematicians that are often working with restricted number of numerical method and algorithms. The AT is demonstrated on PIC implementation (algorithms parallelization/fragmentation and program construction). Methods of the whole program assembling out of atomic fragments of computation are in use already long time in different forms (scalable computing, granularity, etc). Actually AT integrates such well known
296
Assembling of Parallel Programs for Large Scale Numerical Modeling
programming techniques as modular programming and domain decomposition in order to provide suitable technology for the development of parallel programs implementing large scale numerical models. AT supports exactly the process of the whole program assembling out of atomic fragments of computation. Also the peculiarities of numerical algorithm parallel implementation are taken into account. The most close to AT approach to the development of application parallel programs demonstrate the IBM programming system ALF for the microprocessor Cell (ALF for Cell be programmer’s guide and API reference), (ALF for hybrid-x86 programmer’s guide and API reference)
THE PIC METHOD AND THE PROBLEMS OF ITS PARALLEL IMPLEMENTATION The particle simulation is a powerful tool for modeling of the behaviour of complex non-linear phenomena in plasmas and fluids. In the PIC method, trajectories of a huge number of test particles are calculated as these particles are moved under the influence of the electromagnetic fields computed self-consistently on a discrete mesh. These trajectories represent a desirable solution of the system of differential equations describing a physical phenomenon under study (Berezin & Vshivkov, 1980; Hockney & Eastwood, 1981). A real physical space is represented by a model of simulation domain called the space of modeling (SM). The electric E and magnetic B fields are defined as vectors and discretised upon rectangular mesh (or several shifted meshes, as shown in Figs.1 and 2). Thus, as distinct from other numerical methods on the rectangular mesh, in the PIC method there are two different data structures – particles and meshes. None of the particles affects another particle. At any moment of modeling a particle belongs to a certain cell of each mesh. Each charged particle is characterized by its mass, co-ordinates and velocities. Instead of solution of equations in the 6D space of co-ordinates and velocities, the dynamics of the system is determined by integrating the equations of motion of every particle in the series of discrete time steps. At each time step tk+ 1 = tk + Δt the following is done: 1. 2. 3.
4.
For each particle, the Lorentz force is calculated from the values of electromagnetic fields at the nearest mesh points (gathering phase); For each particle the new co-ordinates and velocity of a particle are calculated; a particle can move from one cell to another (moving phase); For each particle the charge carried by a particle to the new cell vertices is calculated to obtain the current charge and density, which are also discretised upon the rectangular mesh (scattering phase); Maxwell’s equations are solved to update the electromagnetic field (mesh phase).
The sizes of a time step and of a cell are chosen in such a manner that a particle cannot fly farther than into the adjacent cell at one time step of modeling. The number of time steps depends on a physical experiment. A more detailed description of the PIC method can be found in (Berezin & Vshivkov, 1980; Hockney & Eastwood, 1981). The PIC algorithm has the great possibility for the parallelisation, because all the particles are moved independently. The volume of computations at the first three phases of each time step is proportional to the number of particles. About 90% of multicomputer resources are spent for the particle processing.
297
Assembling of Parallel Programs for Large Scale Numerical Modeling
Figure 1. A cell of the SM with the electric E and magnetic B fields, discretised upon shifted meshes
Thus, in order to implement the PIC code on multicomputer with high performance, the equal number of particles should be assigned for processing to each processor element (PE). However, on the MIMD distributed memory multicomputers, the performance characteristics of the PIC code crucially depends on how the mesh and particles are distributed among the PEs. In order to decrease the communication overheads at the first and the third phases of a time step, it is required that a PE contains as the cells (values of the electromagnetic fields at the mesh points) as the particles located inside them. Unfortunately, in the course of modeling, some particles might fly from one cell to another. To satisfy the previous requirement, two basic decompositions can be used (Kraeva & Malyshkin, 1997). In the so-called Lagrangian decomposition, the equal number of particles are assigned to each PE with no regard for their position in the SM. In this case, the values of the electromagnetic fields, the current charge and density at all the mesh points should be copied in every PE. Otherwise, the communication overheads at the first and the third phases will decrease the effectiveness of parallelisation. Disadvantages of the Lagrangian decomposition are the following: • •
Strict memory requirements; Communication overheads at the second phase (to update the current charge and the current density in each PE).
Figure 2. The whole space of modeling (SM) assembled out of cells
298
Assembling of Parallel Programs for Large Scale Numerical Modeling
In the Eulerian decomposition, each PE contains a fixed rectangular sub-domain, including electromagnetic fields at the corresponding mesh points and particles in the corresponding cells. If a particle leaves its sub-domain and flies to another sub-domain in the course of modeling, then this particle should be transferred to the PE containing this latter sub-domain. Thus, even with an equal initial workload of the PEs, in several steps of simulation, some PEs might contain more particles than the others. This results in the load imbalance. The character of the particles motion does not fully depend on equations, but also on the initial particles distribution and the initial value of the electromagnetic field. Many researchers studied parallel implementation of the PIC method on different multicomputers. Several methods of the PIC parallelization were developed. The big list of references to articles devoted to PIC parallelization can be found in (Kraeva & Malyshkin, 1997). In order to reach high performance these methods take into account the particles distribution. Let us consider some examples of particles distribution, which correspond to the different real physical experiments. • • •
•
Uniform distribution of the particles in the entire space of modeling. The case of a plate. The space of modeling has n1 × n2 × n3 size. The particles are uniformly distributed in k × n2 × n3size space (k << n1). Flow. The set of particles is divided into two subsets: the particles with zero initial velocity and the active particles with the initially nonzero velocity. Active particles are organized as a flow crossing the space along a certain direction. Explosion. There are two subsets of particles. The background particles with zero initial velocities are uniformly distributed in the entire space of modeling. All the active particles form a symmetric cloud (r << h, where r is the radius of the cloud, h is the mesh step). The velocities of active particles are directed along the radius of the cloud.
The main problem of programming is that the data distribution among the PEs depends not only on the volume of data, but also on the data properties (particles velocities, configuration of electromagnetic field, etc.). With the same volume of data but different particles distributions inside the space the data processing is organized in different ways. As the particles distribution is not stable in the course of modeling, the program control and data distribution among the PEs should be dynamically changing. It is clear that the parallel implementation of the PIC method on a distributed memory multicomputer strongly demands the dynamic load balancing.
BASIC CONCEPTS OF THE TECHNOLOGY OF FRAGMENTED PROGRAMMING Numerical algorithms, generally, and the PIC method, in particular, are very suitable for the application of AT. Considering different approaches to parallel implementation of numerical models it is necessary always to bear in mind, that constructed parallel programs should possess the dynamic properties such as: 1.
Non determinism of execution. The order of processes execution is not fully fixed. The order is chosen in the course of execution for better use of the multicomputer resources.
299
Assembling of Parallel Programs for Large Scale Numerical Modeling
2. 3. 4. 5. 6.
Dynamic tunability of the program to all the available resources. Dynamic resources assignment Dynamic load balancing Program portability Dynamic behavior of the program.
The program should follow to the behavior of the simulated phenomenon. Provision of dynamic properties of a program can be found on the way of the fragmented representation of an algorithm and the program. This affects different stages of an application program development. This is good time to remark that only technological solutions, i.e., the solutions, that can be used in universal technology of program construction, are selected for inclusion into AT. AT provides high quality of implementation of any suitable numerical model. But if a certain numerical model should be implemented with maximally high quality, then with the use of specific algorithms and specific programming techniques the implementing program of more high performance, then under AT, can be developed “manually”.
Algorithm and Program Fragmentation A.
B.
C.
An application problem description should be divided into a system of reasonably small atomic fragments, representing the realization entities of a model. Fragments might be represented in programming languages by variables, procedures, subroutines, macros, nets, notions, functions, etc. An atomic fragment (P_fragment), contains both data and code. In other words, a program, realizing an application problem, is assembled out of such small P_fragments of computations which are connected through variables for data transfer. Under AT the size of atomic fragments can be changed from one to another program execution. The fragmented structure of an application parallel program is kept in the executable code and provides the possibility for organization of flexible and high performance execution of the fragmented program. The general idea is the following. A fragmented program is composed as a set of executable P_fragments. Into every PE a part of P_fragments is loaded that constitute the program for the PE. This program is executed inside every PE, looping over all the P_fragments, loaded to the PE. If these fragments are small enough, then initially for each PE of a multicomputer the equal workload is assembled out of these P_fragments. The workload of PEs can be changed in the course of computation, and if at least one PE becomes overloaded, then a part of P_fragments (with the processing data), which were assigned for execution into the overloaded PE, should migrate to the neighbours underloaded PEs equalizing the workload of multicomputer PEs. Providing dynamic load balancing of a multicomputer, scalability and many other dynamic properties of an application program is based on such a fragmentation.
This is of course a general idea only.
300
Assembling of Parallel Programs for Large Scale Numerical Modeling
Assembling vs. Partitioning Our basic key word is assembly. Contrary to partitioning, the AT supports explicit assembling of a whole program out of ready-made fragments of computations, rather then dividing a problem, defined as a whole, into the suitable fragments to be executed on the different PEs of a multicomputer. These fragments are the elementary blocks, the “bricks”, to construct a whole program. An algorithm of a problem assembling is kept and used later for dynamic program/problem parallelization. Assembling defines the “seams” of a whole computation, the way of the fragments connection. Therefore, these seams are the most suitable way to cut the entire computation for parallel execution. For this reason program parallelization can be always done if the appropriate size of atomic fragments is chosen.
Separation of the Fine Grain and the Coarse Grain Computations The fine grain computations are encapsulated inside a module that realizes the computations bound up with atomic fragment (P_fragment). Such a module can be implemented effectively on a processor element. The whole parallel program is assembled out of these ready-made P_fragments. The set of P_fragments of a program defines a set of interacting processes (coarse grain computations). Encapsulation of the fine grain computations, their complexity, inside an atomic fragment provides the possibility of formalization of a parallel program construction and the use of explicitly two-level representation of an algorithm: the programming level inside an atomic fragment and the scheme level of an application program assembling.
Explicitly Two-Level Programming First, suitable atomic fragments of computation are designed, programmed and debugged separately. Then the whole computation (problem solution) is assembled out of these fragments. As a code for atomic fragment, a sequential library subroutine can be used, for example.
Automatic Providing of Dynamic Properties of a Program Fragmenting an algorithm we should try to satisfy two conditions that not always can be generally satisfied, but for numerical algorithm it might be done: All the processes should consume approximately equal volume of resources. On the set of all the processes there should exist such a partial ordering relation <, that the processes interact only with their neighbours, i.e., process pi can interact with the process pj iff pi < pj & ⌐ p (pi < p < pj) Explicit numerical algorithms on rectangular mesh practically always permit such a fragmentation. Execution of the set of P_fragments can be organized in order their behaviour would imitate the behaviour of a liquid in the system of communicating vessels. This is the technological basis in order uniformly to solve the problem of automatic providing dynamic properties of a target program.
301
Assembling of Parallel Programs for Large Scale Numerical Modeling
Figure 3. Decomposition of SM for implementation of the PIC on the line of PEs
Computation and Communicating in Parallel Into each PE many enough P_fragments are loaded. As result, if one of P_fragments started its communication, the others can continue the computation. Therefore, in the course of the program execution the most of communications can be done in parallel with computations. This is such multiprogramming on the set of P_fragments. Many other properties of a program like library of subroutines accumulation for any platform, program scalability, memory use optimization and go on can be provided by fragmentation too.
Separation of Semantics and Scheme of Computation The fine grain computations define a sufficient part of semantics (functions) of computations. They are realized within an atomic fragment. Therefore, on the coarse grain level, only a scheme (non-interpreted or semi-interpreted) of computations is assembled. It means that formal methods of automatic synthesis of parallel programs (Valkovskii & Malyskin, 1988) can be successfully used and the standard schemes of parallel computations can be accumulated in libraries.
PARALLELIzATION OF NUMERICAL METHODS WITH AT Let us consider the assembly approach to the numerical algorithms parallelisation on the example of the PIC method algorithms parallel implementation. The line and the 2D grid structure of interprocessor communications of a multicomputer are sufficient for the effective parallel implementation of numerical methods on the rectangular meshes. In (Valkovskii & Malyskin, 1988) the algorithm of the 2D grid mapping into the hypercube keeping the neibourhood of PEs is given. A cell is natural atomic fragment of computation for a numerical method implementation. It contains both data (particles inside the cells of a fragment and values of electromagnetic fields, current density at their mesh points) and the procedures, which operate with these data. For the PIC method, when a
302
Assembling of Parallel Programs for Large Scale Numerical Modeling
Figure 4. Decomposition of SM for implementation of PIC on the 2D grid of PEs
particle moves from one cell to another, it should be removed from the former cell and added to the latter cell. Thus, we can say that with the AT the Eulerian decomposition is implemented.
PIC Parallelization on the line of PEs Let us consider first in what way the PIC is parallelized for the multicomputers with the line structure of interprocessor communications. The three-dimensional simulation domain is initially partitioned into N blocks (where N is the number of PEs). Each block_i consists of several adjacent layers of cells and contains approximately the same number of particles (Figure 3). When the load imbalance is crucial, some layers of the block located into an overloaded PE are transferred to another less loaded PE. In the course of modeling, the adjacent blocks are located in the linked PEs. Therefore, the adjacent layers are located in the same or in the linked PEs. It is important for the second phase, at which some particles can fly from one cell into another and for the fourth phase, when for recalculation of values of electromagnetic fields in a certain cell, values in the adjacent cells are also used. Figure 5. Virtual layers for implementation of PIC on the 2D grid of PEs
303
Assembling of Parallel Programs for Large Scale Numerical Modeling
Figure 6. Direction of data transfer for implementation of the PIC on the 2D grid
PIC parallelization on the 2D grid of PEs Let us consider now the PIC method parallelization for the 2D grid of PEs. Let the number of PEs be equal to l × m. Then SM is divided into l blocks orthogonal to a certain axis. Each block consists of several adjacent layers and contains about NP/l particles (in the same way as it was done for the line of PEs). The block_i is assigned for processing to the i-th row of the 2-D grid (Figure 4). Blocks are formed in order to provide an equal total workload of every PE’s row of the processor grid. Then every block_i is divided into m sub-blocks block_i_j, which are distributed for processing among m PEs of the row. These sub-blocks are composed in such a way in order to provide an equal workload of every PE of the row. If overload of at least one PE occurs in the course of modeling, this PE is able to recognize it at the moment when the number of particles substantially exceeds NP/(l × m). Then this PE initiates the re-balancing procedure. If the number of layers k » N (or k » l in the case of the grid of PEs), it is difficult or even impossible to divide the SM into blocks with the equal number of particles. Also, if particles are concentrated inside a single cell, it is definitely impossible to divide SM into the equal sub-domains. In order to attain the better load balance, the following modified domain decomposition is used. A layer containing more than the average number of particles is copied at least into 2 or more neighbouring PEs (Figure 5) – these are virtual layers. A set of particles located inside such a layer are distributed among all these PEs. In the course of the load balancing, particles inside the virtual layers are the first to be redistributed among PEs, and only if necessary, the layers are also redistributed. For the computations inside a PE, there is no difference between virtual and non-virtual layers. Any layer could become virtual in the course of modeling, a virtual layer can stop to be virtual. We can see, that in both cases there is no a necessity to provide flying of a cell. A cell is very small fragment, therefore a large resources should be spent to provide its flying. Thus, there is a necessity to use bigger indivisible fragments on the step of execution (not on the step of a problem/program assembling!). In the case of the line of PEs a layer of the SM should be chosen as indivisible fragment of concrete implementation of PIC. Such a fragment is called a minimal fragment. For PIC implementation on the grid of PEs a column is taken as minimal indivisible fragment. Procedure realizing minimal fragment is composed statically out of P_fragments, before the whole program assembling. This essentially improves the performance of an executable code. In such a way, a cell is used as atomic fragment at the step of numerical algorithm description. At
304
Assembling of Parallel Programs for Large Scale Numerical Modeling
Figure 7. Unification of the Hx mesh variables for two minimal fragments (layers)
the step of execution of a numerical algorithm, different minimal fragments assembled out of atomic fragments are chosen depending on architecture of a multicomputer.
General PIC Method Fragmentation General PIC method fragmentation is based on the dividing of SM into the parallelepipeds. The size of a parallelepiped is chosen in such a way, that several fragments can be loaded into every PE. All the other notions (equal workload, virtual fragments and so on) are defined in the same way. This type of fragmentation is suitable for any current multicomputers.
IMPLEMENTATION OF THE PIC METHOD ON MULTICOMPUTERS Using AT PIC method has been implemented on different multicomputer systems. In order to provide a good portability the language C was chosen for the parallel PIC code implementation. For the dynamic load balancing of PIC several algorithms were developed (Kraeva & Malyshkin, 1999), (Kraeva & Malyshkin, 2001). In the cases of the grid communication structure (Figure 6) and the virtual fragments (particles might fly not only to the neighbouring PEs) special tracing functions are used. According to the AT the array of particles is divided into N parts, where N is the number of minimal fragments (layers of SM in the case of the line of PEs, and columns and parallelepiped in the case of the 2D grid). When elements of the mesh variables (electromagnetic fields, current charge and density) of different minimal fragments hit upon the same point of SM, they are unified (Figure 7). The elements of the mesh variables of one minimal fragment are not added to the data structure for this fragment, but are stored in the 3D arrays with elements of the mesh variables of other minimal fragments in the PE. This appears possible due to the rectangular shape of blocks block_i (block_i_j in the case of the 2D grid). Such a decision allows us to decrease the memory requirements and to speed up computations during the fourth phase of the PIC algorithm. In the case of dynamic load balancing, when some minimal fragments are transferred from one PE to another, the size of the 3D arrays of elements of the mesh variables is dynamically changed. This demands special implementation of such dynamic arrays. In the case of mesh fragmentation into parallelepiped, dynamic load balancing is reached by the fragments migration only.
305
Assembling of Parallel Programs for Large Scale Numerical Modeling
DYNAMIC LOAD BALANCING To attain a high performance of parallel PIC implementation, a number of centralized and decentralized load balancing algorithms were especially developed.
Initial Load Balancing A layer of cells is chosen as minimal fragment for the PIC implementation on the line of PEs. Each minimal fragment has its own weight. The weight of a minimal fragment is equal to the number of particles in this fragment. The sum of weights of all the minimal fragments in some PE determines the workload of PE. The 3D simulation domain is initially partitioned with a certain algorithm into N blocks (where N is the number of PEs). Each block consists of several adjacent minimal fragments and contains approximately the average number of particles. For the initial load balancing two heuristic centralized algorithms were designed (Kraeva & Malyshkin, 1999), (Kraeva & Malyshkin, 2001). These algorithms employ the information about the weights of all the minimal fragments. Each PE has this information and constructs the workload card by the same algorithm. The workload card contains the list of minimal fragments that should be loaded to the PEs. If the number of minimal fragments is much greater than the number of PEs, it is usually possible to distribute the minimal fragments among the PEs in such a way that every block would contain approximately the same number of particles. If considerable portion of particles is concentrated inside a single cell, it is impossible to divide the SM into the blocks with quite an equal workload. To solve this problem, a notion of virtual layer is introduced. The centralized algorithm was modified for the case of virtual fragments. If overloading of at least one PE occurs in the course of modeling, this PE is able to recognize it at the moment when the number of particles substantially exceeds NP/N. Then this PE initiates the rebalancing procedure.
Dynamic Load Balancing If a load imbalance occurs, the procedure BALANCE is called. In this procedure, the decision about the direction of data transfer and the volume of data to be transferred is taken. For any load balancing algorithm there exists its own realizing procedure BALANCE. The procedure TRANSFER is used for the data transfer. There are two implementations of this procedure: for the line of PEs and for the grid of PEs. The procedure TRANSFER is the same for any load-balancing algorithm on the line of PEs. Parameters of the procedure are the number of particles to be exchanged and the direction of data transfer. Let us consider algorithms of the dynamic load balancing of the PIC. All the PEs are numerated. In the case of the line of PE, each PE has number i, where 0 ≤ i ≤ number_of_PEs. In the case of the (l*m) grid of PEs, the number of PE is the pair (i, j), where 0 ≤ i ≤ l, 0 ≤ j < m. In the same way, layers and columns of the SM are numerated.
Centralized Dynamic Load Balancing Algorithm For the dynamic load balancing the initial load balancing algorithm can be used. One of PEs collects the information about weights of the minimal fragments and broadcasts this information to all the other PEs. All the PEs build the new load card. After that neighbouring PEs exchange minimal fragments
306
Assembling of Parallel Programs for Large Scale Numerical Modeling
Figure 8. Review window for Hx mesh variable of an atomic fragment of computation
according to the information in the new workload card. Imbalance threshold. If centralized algorithms are used for the dynamic load balancing, the PEs exchange the information about load balancing, therefore every PE has information about the number of particles in all the PEs. In any PE, the difference mnp-NP/N (where mnp is the maximum number of particles in PE, NP is the total number of particles, N is the number of PEs) is calculated. If the difference is more than the threshold Th, the procedure BALANCE is called. The threshold can be a constant, chosen in advance, or an adaptive number. In the latter case, initially Th=0. In the course of modeling, the time t_part, which is required to implement steps (1-3) of the PIC algorithm for one particle, is calculated. After every BALANCE call the time of balancing t_bal is calculated. Th is assigned to be equal to t_bal/t_part (how many particles could be processed for the same time as one balancing requires). After each subsequent step of the PIC algorithm, Th is decreased by mnp-NP/N. When the value of Th is negative, BALANCE is called. If the threshold is always equal to zero, the procedure BALANCE is called after each time step of modeling.
Decentralized Dynamic Load Balancing Algorithm for the Constant Number of Particles The use of centralized algorithms is good enough for multicomputers containing a few PEs. But if the number of PEs is big enough, the communication overheads could neutralize the advantages of the dynamic load balancing. In this case it is more preferable to use decentralized algorithms. Such algorithms use information about the load balance in the local domain of PEs only. If the number of test particles is not changed in the course of modeling, a simple decentralized algorithm could be suggested. Each PE has the information on how many particles were moved to/from its neighbouring PEs. To equalize the load it is sufficient just to receive/send the same number of particles from/to the neighbouring PEs. It should be noted that this algorithm works in the case of virtual fragments only.
307
Assembling of Parallel Programs for Large Scale Numerical Modeling
Specialized Decentralized Algorithm To equalize the load balance for the PIC implementation, the following specialized algorithm was designed. In the course of simulation in every PE the main direction of particles motion is calculated from the values of particles velocities. In the load balancing, particles are delivered to the direction opposite to the main direction. As in the previous algorithm it is assumed that the number of particles is not changed in the course of simulation. The number of particles to be transferred from overloaded PEs to their neighbours in the direction opposite to the main direction is calculated from the average number of particles and the number of particles in the PE. Some particles are transferred in advance, in order to reduce the number of calls of the dynamic load balancing procedure. This is the case of dynamic behavior of the program when the program “feels” the behavior of the model.
Diffusive Load Balancing Algorithms The basic diffusive load-balancing algorithm was implemented and tested for the PIC parallel implementation (Kraeva & Malyshkin, 1999), (Kraeva & Malyshkin, 2001), (Kuksheva, Malyshkin, Nikitin, Snytnikov, Snytnikov, & Vshivkov, 2001). The size of the local domain is equal to two. Any diffusive algorithm is characterized by the number of steps. Actually the number of steps defines how far the data from one PE could be transferred in the course of load balancing. For every step the procedure TRANSFER is called. The more the number of steps of diffusive algorithm the better load balance could be attained, but also the more time is required for load balancing. The tests have shown that the total program time does not decrease with the growth of the number of steps.
AUTOMATIC GENERATION OF PARALLEL CODE The PIC method is applied to simulation of many natural phenomena. In order to facilitate the parallel PIC implementation, a special system of parallel program automatic generation was designed. This system consists of the VISual system of parallel program Assembling (VisA) and a parallel code generator in C language. The process of the generation of a parallel program for the PIC (and the same way for the other numerical algorithms on the rectangular meshes) consists of three steps. At the first step, a user defines the atomic fragment of computation – a cell of the SM. This cell contains elements of the mesh variables at several mesh points, an array of particles (for PIC method) and procedures in C language, which describe all the computations inside the cell – {procedure1,…, procedurek} (Figure 8). At the second step the description of assembling of the minimal fragments out of atomic fragments is done in visual system VisA, after that the whole computation is assembled in the manner like a wall is assembled out of the bricks. After that the generator constructs a program for implementation of the defined minimal fragment (a layer, a column or a parallelepiped). The particle arrays of atomic fragments merge to a single particle array for the minimal fragment. The elements of the mesh variables, which hit upon the same point of SM, are unified. In such a way, for every mesh variable, only one 3D array of its elements is formed. At the third step, the decision on the PEs workload is made. The generator creates a parallel program
308
Assembling of Parallel Programs for Large Scale Numerical Modeling
implementing the whole computation for a target multicomputer. This program includes data initialization and a time loop. At each iteration of the time loop, k loops (where k is the number of procedures in the description of an atomic fragment) over all the minimal fragments of PE run. After each k-th loop, those elements of the mesh variables, which are copied in several PEs, are updated (if necessary). All the particles are stored in m arrays (where m is the number of minimal fragments in a certain PE). However, similarly the case of the minimal fragment assembling, the elements of a mesh variable in all the minimal fragments of a PE form one 3D array. The user develops procedures (computations inside a cell) in C language, using also several additional statements for defining the computations over the mesh variables.
CONCLUSION The AT provids high performance of an assembled program execution, its high flexibility in reconstruction of the code and dynamic tunability to available resources of a multicomputer. High performance of the program execution provides modeling of large scale problems such as the study of a cloud plasma explosion in the magnetized background, modeling of interaction of a laser impulse with plasma, astrophysical problems solution, etc. We applied the AT to implementation of different numerical methods and hope to create a general tool to support implementation of mathematical approximating models. Finally the question can be given: “How many numerical algorithms can be fragmented?” The answer to this question can be found in (Malyskin, Sorokin & Chauk, 2008). The answer is: any numerical mass algorithm can be fragmented, but with the different results. In order to reach good result many efforts should made. Very often a deep modification of initial algorithms should be done similar to the algorithms modification for their parallelization. But this is another topic for consideration.
REFERENCES ALF for Cell BE Programmer’s Guide and API Reference. Retrieved from http://www01.ibm.com/chips/ techlib/techlib.nsf/techdocs/41838EDB5A15CCCD002573530063D465 ALF for Hybrid-x86 Programmer’s Guide and API Reference. Retrieved from http://www01.ibm.com/ chips/techlib/techlib.nsf/techdocs/389BBE99638335B80025735300624044 Berezin, Y. A., & Vshivkov, V. A. (1980). The method of particles in rarefied plasma dynamic. Novosibirsk, Russia: Nauka (Science). Corradi, A., Leonardi, L., & Zambonelli, F. (1997). Performance comparison of load balancing policies based on a diffusion scheme. In Proc. of the Euro-Par’97 (LNCS Vol. 1300). Springer: Germany. Hockney, R., & Eastwood, J. (1981). Computer simulation using particles. London: McGraw-Hill, Inc.
309
Assembling of Parallel Programs for Large Scale Numerical Modeling
Kedrinskii, V. K., Vshivkov, V. A., Dudnikova, G. I., Shokin, Yu. I., & Lazareva, G. G. (2004). Focusing of an oscillating shock wave emitted by a toroidal bubble cloud. Journal of Experimental and Theoretical Physics, 98(6), 1138–1145. doi:10.1134/1.1777626 Kraeva, M. A., & Malyshkin, V. E. (1997). Implementation of PIC method on MIMD multicomputers with assembly technology. In Proc. of the High Performance Computing and Networking Europe 1997 Int. Conference. (LNCS, Vol.1255), (pp. 541-549). Berlin: Springer Verlag. Kraeva, M. A., & Malyshkin, V. E. (1999). Algorithms of parallel realization of PIC method with assembly technology. In Proceedings of 7th High Performance Computing and Networking Europe, (LNCS Vol. 1593), (pp. 329-338). Berlin: Springer Verlag. Kraeva, M. A., & Malyshkin, V. E. (2001). Assembly technology for parallel realization of numerical models on MIMD-multicomputers. International Journal on Future Generation Computer Systems, Elsevier Science, 17(6), 755–765. doi:10.1016/S0167-739X(00)00058-3 Kuksheva, E. A., Malyshkin, V. E., Nikitin, S. A., Snytnikov, A. V., Snytnikov, V. N., & Vshivkov, V. A. (2005). Supercomputer simulation of self-gravitating media. International Journal on Future Generation Computer Systems, 21(5), 749–758. doi:10.1016/j.future.2004.05.019 Malyshkin, V. (2006). How to create the magic wand? Currently implementable formulation of the problem. In New Trends in Software Methodologies, Tools and Techniques, Proceedings of the Fifth SoMeT_06, 147, 127-132. Malyshkin, V. E. (1995). Functionality in ASSY system and language of functional programming. In Proceedings of the First Aizu International Symposium on Parallel Algorithms/Architecture Synthesis. (pp. 92-97). Aizu-Wakamatsu, Japan: IEEE Comp. Soc. Press. Malyshkin V.E., Sorokin S.B., & K.G.Chauk (2008, May). Fragmented numerical algorithms for the library parallel standard subroutines. Accepted to publication in Siberian Journal of Numerical Mathematics, Novosibirsk, Russia. Snytnikov, V. N., Vshivkov, V. A., Kuksheva, E. A., Neupokoev, E. V., Nikitin, S. A., & Snytnikov, A. V. (2004). Three-dimensional numerical simulation of a nonstationary gravitating n-body system with gas. Astronomy Letters, 30(2), 124–138. doi:10.1134/1.1646697 Valkovskii, V. A., & Malyshkin, V. E. (1988). Synthesis of parallel programs and systems on the basis of computational models. Novosibirsk, Russia: Nauka. Vshivkov, V. A., Nikitin, S. A., & Snytnikov, V. N. (2003). Studying instability of collisionless systems on stochastic trajectories. JETP Letters, 78(6), 358–362. doi:10.1134/1.1630127 Walker, D. W. (1990). Characterising the parallel performance of a large-scale, particle-in-cell plasma simulation code. International Journal on Concurrency: Practice and Experience., 2(4), 257–288. doi:10.1002/cpe.4330020402
310
Assembling of Parallel Programs for Large Scale Numerical Modeling
KEY TERMS AND DEFINITIONS Assembly Technology: Technology of parallel programs development for large scale numerical simulation based on assembling of the whole computation out of atomic fragments of computation. The technology integrates well known techniques of modular programming and domain decomposition and is supported by the system software. Cluster: A multicomputer with the tree structure of communication net. Dynamic Load Balancing: Equalizing of workload of multicomputer processor elements in the course of a program execution in order to reach better multicomputer performance. Dynamic Tunability of a Program to All the Available Resources: A program should be able to use all the available resources of a multicomputer. Multicomputer: A set of computers connected by the communication net and able with the use of special system software to solve jointly the same application problem. Well known examples of multicomputer’s communication net are rectangular mesh, tree, torus, hypercube. Parallel Programming: The development of programs able to be executed on multicomputers. Particle-In-Cell Method: Widely used numerical method for direct simulation of natural phenomena where the material is represented by the huge number of test particles. Instead of solution of the system of partial differential equations in the 6D space of co-ordinates and velocities, the dynamics of a simulated phenomenon is determined by integrating the equations of motion of every particle in the series of discrete time steps. The method began to be applicable with the use of supercomputers only.
311
312
Chapter 14
Cell Processing for two Scientific Computing Kernels Meilian Xu University of Manitoba, Canada Parimala Thulasiraman University of Manitoba, Canada Ruppa K. Thulasiram University of Manitoba, Canada
ABSTRACT This chapter uses two scientific computing kernels to illustrate challenges of designing parallel algorithms for one heterogeneous multi-core processor, the Cell Broadband Engine processor (Cell/B.E.). It describes the limitation of the current parallel systems using single-core processors as building blocks. The limitation deteriorates the performance of applications which have data-intensive and computationintensive kernels such as Finite Difference Time Domain (FDTD) and Fast Fourier Transform (FFT). FDTD is a regular problem with nearest neighbour comminuncation pattern under synchronization constraint. FFT based on indirect swap network (ISN) modifies the data mapping in traditional CooleyTukey butterfly network to improve data locality, hence reducing the communication and synchronization overhead. The authors hope to unleash the Cell/B.E. and design parallel FDTD and parallel FFT based on ISN by taking into account unique features of Cell/B.E. such as its eight SIMD processing units on the single chip and its high-speed on-chip bus.
INTRODUCTION High performance computing (HPC) clusters provide increased performance by splitting the computational tasks among the nodes in the cluster and have been commonly used to study scientific computing applications. These clusters are cost effective, scalable and run standard software libraries such as MPI which are specifically designed to develop scientific application programs on HPC. They are also comparable in performance speed and availability to supercomputers.A typical example is the Beowulf cluster DOI: 10.4018/978-1-60566-661-7.ch014
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Cell Processing for two Scientific Computing Kernels
which uses commercial off-the-shelf computers to produce a cost-effective alternative to a traditional supercomputer. In the list of top 500 fastest computers in top500.org, many of them are pure clusters. One of the crucial issue in clusters is the communication bandwidth. High speed interconnection networks such as Infiniband have paved the way for increased performance gain in clusters. However, the development trend in clusters has been greatly influenced by hardware constraints leading to three walls called brick wall (Asanovic et al., 2006). According to Moore’s law, the number of transistors on the chip will double every 18 to 24 months. However, the speed of processor clocks has not kept up with the increased transistor design. This is due to the physical constraints imposed on clock speed increase. For example, too much heat dissipation leads to complicated cooling techniques to prevent the hardware from deteriorating. And too much power consumption daunts the customers from adopting new hardware, increasing the cost of commodity applications. Power consumption is doubling with the doubling of operating frequency leading to the first of the three walls, power wall. On the other hand, even with the increased processor frequency achieved so far, the system performance has not improved significantly in comparison to the increased clock speeds. In many applications, the data size operated on by each processor changes dynamically, which in turn, affects the computational requirements of the problem leading to communication/synchronization latencies and load imbalance. Multithreading is one way of tolerating latencies. However, previous research (Thulasiram & Thulasiraman, 2003; Thulasiraman, Khokhar, Heber, & Gao, 2004) has indicated that though multithreading solves the latency problem to some extent by keeping all processors busy exploiting parallelism in an application, it has not been enough. Accessing data in such applications greatly affects memory access efficiency due to the non-uniform memory access patterns that are unknown until runtime. In addition, the gap between the processor speed and memory speed is widening as processor speed increases more rapidly than memory speed leading to the second wall, memory wall. To solve this problem, many memory levels are incorporated which requires exotic management strategies. However, the time and effort required to extract the full benefits of these features detracts from the effort exerted on real coding and optimization. Furthermore, it has become a very difficult task for algorithm designers to fully exploit instruction level parallelism (ILP) to utilize the processor resources effectively to keep the processors busy. Solutions to this problem have been in using deep pipelines with out-of-order execution. However, this approach impacts the performance of the algorithm due to the high penalty paid on wrong branch predictions. This leads to the third wall, ILP wall. These three walls force architecture designers to develop solutions that can sustain the requirements imposed by applications and provide solutions to some of the problems imposed by hardware in traditional multiprocessors. A multi-core architecture is one of the solutions to tackle the three walls. These architectures are driven by the need for decreased power consumption, increased operations/watt and Moore’s Gap. A multi-core architecture consists of a multi-core processor, which is also called a chip-level multiprocessor (CMP). A multi-core processor combines two or more independent cores into a single die. It is a new architecture and cannot be regarded as a new SMP (Symmetric MultiProcessor) architecture since all cores in this architecture share on-chip resources while separate processors in the conventional SMP do not. For example, each core of AMD Opteron dual-core processor has its own L2 cache, but the two cores still share other interconnect to the rest of system such as the memory controller. These dual-core processors belong to homogeneous multi-core processors because the resources and execution units (or cores) are mere replications of each other. The number of cores on a single die is still growing. Quad-Core Intel Xeon processor and Quad-Core AMD Opteron processor are already available. Cyclops64 has as many as 64 homogeneous cores on a single chip, which is usually known as a many-core architecture. On the
313
Cell Processing for two Scientific Computing Kernels
other hand, the IBM Cell Broadband Engine (Cell/B.E.) processor is a heterogeneous multi-core processor (Chen, Raghavan, Dale, & Iwata, 2007), which has one conventional microprocessor, Power Processor Element (PPE), and eight SIMD co-processing elements called Synergistic Processor Elements(SPEs). PPE and SPEs use different Instruction Set Architecture (ISAs). These devices communicate with one another by an ultra speed broadband connection called the Element Interconnect Bus (EIB). The PPE, a superscalar RISC processor, acts as the central controller for the SPEs and provides multithreaded support to better utilize the resources of modern processor architectures. Just as the neuron cells in the brain work together, the Cell incorporates many electronic devices to work together as a complete system. The Cell is, therefore, a System-on-Chip or heterogeneous multi-core architecture. The concept of multi-core architectures and its implementations have paved the way to building tera- and peta-scale supercomputer systems. Los Alamos Roadrunner, an Opteron-Cell hybrid supercomputer, aims at providing a sustained petaflop supercomputer based on AMD Opteron multi-core processors and Cell/B.E. processors. The concept of multiprocessors is not new. It has existed in other hardware designs such as GPU (Graphics Processing Unit), FPGA (Field Programmable Gate Array), and network processors. In this chapter, we design and develop parallel algorithms for two scientific computing kernels, FDTD (Finite-Difference Time-Domain) and FFT (Fast Fourier Transform) on multicore architecture,in particular the Cell/B.E. FDTD is a regular scientific computing problem which has its applications in electromagnetic theory and medical imaging (Xu, Sabouni, Thulasiraman, Noghanian, & Pistorius, 2007). It follows nearest neighbour communication pattern and is synchronous in nature. The FDTD is computationally data intensive and is usually a kernel in the applications. Therefore, improving the FDTD algorithm is very important to the overall performance of the application. The FFT is a semi-irregular problem and a kernel in many applications such as computed tomography and option pricing in finance (Barua, Thulasiram, & Thulasiraman, 2005). The partners of the butterfly computation change at each iteration thereby changing the communication pattern at each iteration. In the FFT algorithm the processors can be only one iteration ahead of their neighbouring processors. In this chapter we explain the Indirect Swap Networks (ISN) technique, an idea proposed in VLSI circuits that can be efficiently used to compute the butterfly computations in FFT. Data mapping in the swap network topology reduces the communication overhead by half at each iteration compared to the traditional Cooley-Tukey algorithm. The rest of the chapter is organized as follows. Section 0 introduces in detail the Cell/B.E. which brings new challenges to parallel algorithm design. FDTD is described in Section 0. The parallel FDTD algorithms for distributed memory machines and homogeneous muilticore processors are provided in Section 0 and Section 0 respectively. Section 0 explains the parallel algorithm design on the Cell/B.E. The experimental results of these three parallel algorithms are presented in Section 0. FFT is described in Section 3. An introduction to FFT is provided in Section 3. The indirect swap network in explained in Section 3. The algorithm based on ISN is parallelized on the Cell/B.E. and is explained in Section 4 followed by experimental results in Section 5. The experience of exploiting multicore processors for these two scientific computing kernels is summarized in Section 8 which concludes this chapter.
CELL BROADBAND ENGINE PROCESSOR Applications that require stream lining of data and instructions are more suitable for vector processors such as Cray X-MP supercomputers existed in the 1980s to 1990s. In the recent years, there have been several other vector computer architectures such as NEX XS series, Cray X1, Fujitsu vector systems,
314
Cell Processing for two Scientific Computing Kernels
Hitachi SR8000 emulating vector architectures. Furthermore, the SSE instructions in regular Intel processors introduce vector instruction (even if for very short vector length) to regular proccessor chips. The Cell/B.E. is also an architecture to support vector operations(Chen et al., 2007). One of Cell/B.E.’s unique features, the Single Instruction Multiple Data (SIMD) computing, allows data level parallelism and moves towards vector processing. The Cell/B.E. processor is the first implementation of the Cell Broadband Engine Architecture (CBEA) (Chen et al., 2007). CBEA was implemented to address some of the issues related to the three walls existing in conventional uni-processor systems. The Cell/B.E. processor is a heterogeneous multi-core processor. It consists of one conventional 64-bit Power Processor Element (PPE), eight Synergistic Processor Elements (SPEs), a memory controller, an I/O controller, and an on-chip coherent bus EIB (Element Interconnect Bus) which connects all elements on the single chip. The eight SPEs are purposely designed for intensive computing via large number of wide uniform registers (128-entry 128-bit registers) and 256KB local store for each SPE. The Memory Flow Controller (MFC) on each SPE and the high bandwidth EIB (with a peak bandwidth of 204.8 GBytes/s) enable SPEs to interact with PPE, with other SPEs, and with main memory efficiently. The novice features make the Cell/B.E. processor an attractive and well suited for scientific computing applications (Williams et al., 2006). The Cell/B.E. processor exhibits several levels of parallelism. Coarse-grained parallelism exists between the PPE and SPEs, and between different SPEs. The PPE and SPEs can work on different tasks concurrently. Each SPE can also perform different tasks simultaneously. Fine-grained parallelism can be implemented both on the PPE and on the SPE. Both the PPE and the SPEs have their own SIMD instruction sets, each capable of executing two instructions per clock cycle. The PPE has a two-way multi-threaded hardware support and is a dual-issue in-order processor. The SPE does not support multithreaded on the hardware level, however, it is also a dual-issue in-order processor because of its two pipelines. Also, the MFC of each SPE can move data around without interrupting the ongoing tasks on the PPE and SPEs. The nature of parallelism on the Cell/B.E. processor is expected to produce significant performance improvement if fully explored and utilized (Chen et al., 2007). All these features make the Cell/B.E. processor an attractive and new architecture for compute intensive applications. Liu et al. (Liu et al., 2007) develop a digital media indexing application on Cell/B.E.. Williams et al. (Williams et al., 2006) investigate the performance of several key scientific computing kernels on Cell/B.E. processor. They conclude that the Cell/B.E. processor’s three level software-controlled memory architecture (the 128 registers, the LS, and the main memory) outperforms the conventional cache-based architectures, especially for applications with predictable memory access patterns by effective overlap of computation and communication.
FINITE DIFFERENCE TIME DOMAIN ALGORITHM This section explains the Finite-Difference Time-Domain (FDTD) method. FDTD is a popular method in many applications such as electromagnetic theory (Yu, Mittra, Su, Liu, & Yang, 2006) and medical imaging (Xu et al., 2007). FDTD is inherently data-intensive and compute-intensive exhibiting nearest neighbour communication patterns. Since it is usually a kernel in many applications, the performance of the FDTD algorithm to the overall performance of the entire application is crucially important. In this section, we develop parallel FDTD algorithm for the Cell/B.E. and compare the results to two different architectures, distributed memory clusters and homogeneous multicore AMD Opteron. We discuss the
315
Cell Processing for two Scientific Computing Kernels
experimental results and the challenges posed in developing the algorithms taking into consideration the architectural features of these architectures.
Finite Difference Time Domain Algorithm FDTD is a numerical technique proposed by Yee in 1966 to solve Maxwell’s equations in electromagnetics field (Yee, 1966). Yee’s algorithm discretizes the 3D region of interest into a mesh of cubic cells or 2D region into a grid of rectangular cells. These cells are called Yee cells. Each Yee cell has electrical fields( E ) and magnetic fields( H ) when the region is pinged with microwaves. The electrical fields and magnetic fields interleave with each other spatially: the edges of the cells in electrical mesh lie at the center of the cells in magnetic cells. Electrical fields and magnetic fields are updated at alternate half time steps in a leapfrog scheme in time. An application of FDTD for breast cancer detection uses the following equations to model the electrical and magnetic fields update. We refer readers (Xu et al., 2007) for details of the application. E zx |ni,+j 1 = aE zx |ni, j +
b ù ´ éH |n +1/2 -H y |ni -+1,1/2 j úû Dx êë y i, j
(1)
E zy |ni,+j 1 = aE zy |ni, j -
b ù ´ éH |n +1/2 -H x |ni,+j -1/2 1 ûú Dy ëê x i, j
(2)
H x |ni,+j 1/2 = H x |ni,-j 1/2 -g éêE zx |ni, j +1 +E zy |ni, j +1 -E zx |ni, j -E zy |ni, j ùú ë û
(3)
H y |ni,+j 1/2 = H y |in,-j 1/2 +g éêE zx |ni +1, j +E zy |ni +1, j -E zx |ni, j -E zy |ni, j ùú ë û
(4)
1-
sDt 2e0 er
1+
sDt 2e0 er
a=
b=
Dt e0 er (1 +
g=
316
(5)
Dt mDy
sDt ) 2e0 er
(6)
(7)
Cell Processing for two Scientific Computing Kernels
In the equations, E zx |ni,+j 1 is the electrical field at position (i, j) at the time interval (n + 1). H x |ni,+j 1/2 is the magnetic field at position (i, j) at the time interval (n + 1/2). σ is the conductivity of the material. ε0 and εr represent the permittivity of the free space and the material respectively. Μ denotes the permeability of the material. Δt is the time step. Δx × Δy is the size of the Yee cell. A sequential FDTD on a conventional computer is shown in Algorithm 1. N is the number of Yee cells in each direction, assuming that each direction is equally divided. MAX_TIMESTEPS is the max number of time steps (iterations) for field updates. FDTD is the kernel of many applications in electromagnetic field (Taflove & Hagness, 2000; Xu et al., 2007). As an iterative algorithm, its performance is critical to its widespread applications. However, it is computationally intensive and therefore parallel processing is required (Xu et al., 2007). The complexity of a 2D FDTD algorithm is O(N3) The sequential FDTD algorithm takes about 200 seconds for a 600 × 600 computational domain in 4000 time steps on an AMD Athlon 64 X2 Dual Core processor at 2GHz. In medical imaging, finer granularity is a necessity to produce more accurate results. However, increased granularity indicates increased computation time along with more memory requirement. These reasons have led us to design parallel FDTD algorithms for different architectures. A number of parallel FDTD research has been reported using different parallel schemes on different platforms for different applications. Guiffaut et al. (Guiffaut & Mahdjoubi, 2001) implement a parallel FDTD on a computational domain of 150 × 150 × 50 cells on PC and the Cray T3E. They use Message Passing Interface (MPI) and adopt vector communication scheme and matrix communication scheme, obtaining higher efficiency by the latter scheme. Su et al. (Su, EI-kady, Bader, & Lin, 2004) combine OpenMP and MPI to parallelize FDTD: OpenMP used for the one time initialization and each time-step updating of the E-fields and H-fields; MPI is used for the communication between neighboring processors. Yu et al. (Yu et al., 2006) introduce three communication schemes in parallel FDTD. The three schemes differ in which components of E-fields and H-fields should be exchanged and which process should update the E-fields on the interface. Algorithm 1 Sequential FDTD on a conventional computer
Initialize electric fields and magnetic fields; Calculate coefficients for all Yee cell; for n = 1 to MAX_TIMESTEPS do for i = 1 to N do for j = 1 to N do Update Ezx[i][j] using equation 1; Update Ezy[i][j] using equation 2; Update Hx[i][j] using equation 3; Update Hy[i][j] using equation 4; end for end for end for
317
Cell Processing for two Scientific Computing Kernels
FDTD on Distributed-Memory Machines FDTD is data-parallel in nature and exhibits apparent nearest-neighbor communication pattern (Yu et al., 2006). Therefore, FDTD is a suitable algorithm for parallelization on distributed memory machines using Message Passing Interface (MPI). The factors impacting the performance of parallel FDTD on distributed memory machines are communication and synchronization overhead. As shown in the previous section, field updates of each Yee cell requires information from its neighbors. There is no communication overhead if the neighbors of the Yee cells reside on the same processor. However, communication becomes an issue at the border of decomposition where some or all of cells’ neighbors are on the neighboring processors. The computational domain has to be large to provide accurate results which implies the communication overhead is high while transferring large amounts of data. Therefore, overlapping computation with communication is critical to gaining performance. Another nature of FDTD is that the field updates cannot proceed to the next time step until all Yee cells have been updated for the current time step. This incurs synchronization overhead for each time step. Therefore, in designing the parallel FDTD algorithm, proper data distribution and mapping on the available processors is critical to avoiding communication bottlenecks. Yu et al. (Yu et al., 2006) introduce three communication schemes for parallel FDTD. The three schemes differ in which components of E and H should be exchanged and which processor should update the E on the interface. The division of the computational domain is on the E along the Cartesian axis. In this chapter, the computational domain is divided along the x axis of E . Suppose the computation domain is divided into n × n cells and p processors are used for FDTD computation. Then, each processor receives a matrix of m × n cells where m = n/p. Each processor i (i is not equal to 1 and p, the last processor) shares the first and mth row of its computational domain with processor i −1 and i + 1 respectively. Therefore, E on the interface of adjacent processors are calculated on both processors. The purpose of the scheme is to eliminate the communication of E and only communicate H , trying to improve the computation/communication efficiency. The parallel FDTD algorithm, referred to as MPI-version parallel FDTD algorithm, is given in Algorithm 2. Algorithm 2 Parallel FDTD on distributed-memory machines (MPI-version parallel FDTD)
Initialize electric fields and magnetic fields; if processor is master processor then Calculate coefficients for all Yee cells; Decide the Yee cells for each processor and send coefficients of those Yee cells to the corresponding processors; else Receive the coefficients of the Yee cells residing on the local processor; end if forn = 1 to MAX TIMESTEPSdofori = 1 to N=Pdoforj = 1 to Ndo Update Ezx[i][j] using equation 1; Update Ezy[i][j] using equation 2; Update Hx[i][j] using equation 3;
318
Cell Processing for two Scientific Computing Kernels
Update Hy[i][j] using equation 4; end for end for Exchange magnetic fields with the neighboring processors; Synchronize among all processors end for if processor is not master processor then Send the final results to master processor; else Receive results from all other processors; Output the results at the observation points; end if
FDTD on Homogeneous Multicore Achitecture The multicore machine available for this work is a Sun Fire X4600 serverIt is configured with eight sockets. Each socket is configured with an AMD Opteron dual-core processor. The processors are connected with AMD HyperTransport Technology links. As a whole system, it is a ccNUMA(cache-coherent Non-Uniform Memory Access) SMP system. Each processor has its dedicated memory attached to two cores. It can access the memory of other processors via AMD’s unique Direct Connect Architecture (DCA). AMD Opteron dual-core processors have interesting design technologies to tackle some aspects of the three walls. Each core has separate L1 and L2 cache. Separate L2 caches prevent potential synchronization bottleneck for multiple threads on multiple cores competing over the same data cache. Hence, separate cores can process separate data sets, avoiding cache contention and coherency problems. Furthermore, AMD has a unique implementation of ccNUMA based on DCA. Inside each of the eight dual-core processors, there is a cross-bar switch. One side of the switch attaches the two cores. The other side of the switch attaches the DCA with a shared memory controller and HyperTransport Technology links. The shared memory controller connects the two cores to dedicated memory. The HyperTransport Technology links allow dual cores on one processor access to another processor’s dedicated memory. Therefore, for each core, some memory is directly attached, yielding a lower latency, while some is not directly attached and has a higher latency. The combination of ccNUMA and DCA technology can improve performance by locating data close to the thread that needs it, which is called “memory affinity”. Besides, the hypervisor which virtualizes the underlying multi-core processor and multi-processor system, provides facilities to specify “thread affinity” to assign dedicated cores for threads. This facility contributes to further performance improvement. Although FDTD is computationally intensive, it shows apparent data parallelism and high data locality property. Each Yee cell update, both for electrical fields and for magnetic fields, only needs information of its near neighbors as shown in equation 1 through equation 4. Locality is one of the key factors that impact performance on cache-based computers. The inherent locality property of FDTD may bring significant performance on the homogeneous multi-core system via shared-memory parallel programming paradigm, especially with the hardware support of separate L2 cache for each core. Therefore, we designed a shared-memory version of FDTD as shown in Algorithm 3, which we refer to as OpenMP version parallel FDTD.
319
Cell Processing for two Scientific Computing Kernels
Algorithm 3 Parallel FDTD on shared memory machines (OpenMP-version parallel FDTD)
Initialize electric fields and magnetic fields; Calculate coefficients for all Yee cell; forn = 1 to MAX_TIMESTEPSdo #pragma omp parallel { #pragma for private(i, j) fori = 1 to Ndoforj = 1 to Ndo Update Ezx[i][j] using equation 1; Update Ezy[i][j] using equation 2; Update Hx[i][j] using equation 3; Update Hy[i][j] using equation 4; end for end for } end for
FDTD on Cell/B.E. Processor This section will list the key issues to fully utilize the parallelism of Cell/B.E. for FDTD. One issue is the limited size of the local store (LS) on each SPE. The 256KB LS is for both instructions and data. Based on the equations (1) to equation (4), for a computational domain of 600 × 600 Yee cells, 16M memory is needed to hold the variables for the coefficients and the fields at run time, without considering the code and other variables. Therefore, one of the main issues is to decide on how to make the data fit in the limited memory size at run time. A solution to this issue is we let each SPE consider a part of the computational domain once. At each time step, the SPE fetches the coefficients and the field values of the Yee cells within the part of the computational domain, and updates the fields using the equations. The updated field values are stored back to the corresponding memory locations to make space for the next part of the computational domain. The SPE then starts with the next part of the domain. The process continues until all the Yee cells of the computational domain are updated for the current time step. Another round of the whole process starts for the next time step for MAX_TIMESTEPS rounds. By fetching and storing data between the main memory and the LS, each SPE can manage the LS to have instructions and data under 256KB limit at run time. Another issue is how to decide on the size and the frequency of exchanging data between the memory and the LS such that the Cell/B.E. processor is fully utilized . The SPEs can only operate on instructions and data residing on the LS. Unlike the PPE, SPEs cannot access the main memory directly. It has to fetch instructions and data from the memory to the LS using asynchronous coherent DMA commands. Therefore, the communication cost must be considered during algorithm design. A suitable size and frequency for the transfers has to be determined to ensure there is no data starvation and there is minimal overhead. Several points are critical in reducing the communication cost and achieving efficient SPE data access: data alignment, access pattern, DMA initiator, and location. The MFC of the SPE supports
320
Cell Processing for two Scientific Computing Kernels
transfers of 1,2,4,8 and n × 16 (up to 16K) bytes. Transfers less than 16 bytes must be naturally aligned and have the same quad-word offset for the source and the destination addresses. Also, all transfers cannot be completed without the EIB. Hence, the cost on the EIB must be minimized. A minimal overhead of the EIB can be achieved if transfers are at least 128 bytes, and transfers greater than or equal to 128 bytes are cache-line aligned, i.e., aligned to 128 bytes. Furthermore, whenever possible we let SPE initiate the DMAs and pull the data from the main memory instead of PPE’s L2 cache. MFC transfers from the system memory have high bandwidth and moderate latency, whereas transfers from L2 cache have moderate bandwidth and low latency. The third issue is the synchronization problem when more than one SPE is used to explore the parallelism between SPEs. Algorithm 0 shows that the field update for all Yee cells must be completed for the current time step before any Yee cells can be dealt with further for the next time step. Therefore, when more than one SPE is used to update different part of the computational domain, the synchronization among all participant SPEs is mandatory for correct results. The Cell/B.E. processor supports different synchronization mechanisms (Chen et al., 2007): MFC atomic update commands, mailboxes, SPE signal notification registers, events and interrupts, or just polling of the shared memory. We consider the mailboxes and SPE signal notification registers in the paper. For the first method, SPEs use mailboxes while PPE acts as the arbitrator. When each SPE finishes its tasks for the current time step, it uses mailbox to notify the PPE that it is ready for the next time step. When the PPE receives messages from all participant SPEs, it sends a message via mailboxes to those SPEs and lets the SPEs start the task for the next time step. The PPE is not involved for SPE signal notification registers method. One SPE acts as the master SPE, and other SPEs are slave SPEs. The slave SPEs send signals to the master SPE when their tasks for the current time step is completed, and wait for the signal of starting the task for the next time step from the master SPE. The master SPE sends such signal only when it receives signals from all slave SPEs. The last issue is on the implementation level: the exploitation of SIMD on the SPE. SPEs are SIMDonly co-processors. Scalar codes, especially codes for arithmetic operations, may deteriorate the performance since the SPE has to re-organize the data and instructions to be executed on the SPE. The code written in a high-level language must rely on the compiler technology to be auto-vectorized to exploit SIMD capability of the SPE. However, the flexibility of high-level languages makes it difficult to achieve optimal results for different applications. Therefore, explicit control of the instructions by the programmers is a detrimental for optimal performance. For this purpose, the SPE provides intrinsics which are essentially inline assembly code with C function call syntax. These intrinsics provide such functions as register coloring, instruction scheduling, data loads and stores, looping and branching, and literal vector construction. The paper considers literal vector constructions since most of the tasks for FDTD are arithmetic operations. It aims to manually apply SIMD to the two FOR loops shown in Algorithm 1. Based on all the issues and solutions, we designed a parallel FDTD algorithm as shown in Algorithm 5 (referred as CellBE-version parallel FDTD) for the SPE side respectively. The PPE is used to manage all SPE threads and calculate the intializatin values. The purpose is to fully exploit the natural parallelism provided by the processor in order to achieve significant performance improvement. Algorithm 5 FDTD on the SPE (CellBE-version parallel FDTD)
Send ready singal to the PPE; Receive information for synchronization;
321
Cell Processing for two Scientific Computing Kernels
DMA in control block to get information about its task assigned and running setting; for n = 1 to MAX TIMESTEPS do while Ezx of Yee cells not updated do Fetch chunks of data, including the coefficients and the field values of last time step; Update Ezx using SIMD version of equation 1; Store the updated Ezx back to the corresponding memory location; end while while Ezy of Yee cells not updated do Fetch chunks of data, including the coefficients and the field values of last time step; Update Ezy using SIMD version of equation 2; Store the updated Ezy back to the corresponding memory location; end while while Hx of Yee cells not updated do Fetch chunks of data, including the coefficients and the field values of last time step; Update Hx using SIMD version of equation 3; Store the updated Hx back to the corresponding memory location; end while while Hy of Yee cells not updated do Fetch chunks of data, including the coefficients and the field values of last time step; Update Hy using SIMD version of equation 4; Store the updated Hy back to the corresponding memory location; end while Synchronize with other SPEs; end for Send finish signal to the PPE;
Experiment Results and Comparisons The three parallel algorithms were designed for three architectures: distributed memory machines, homogeneous multicore machines and the Cell/B.E. processor. They were run on four configurations. We use processing unit number as x axis to avoid confusion between processor number, thread number, core number, and SPE number. Although PPE is used for part of the computation, its contribution to the final performance is negligible compared to the computation on the SPEs. Therefore, the processing unit number indicates the number of SPEs for the Cell/B.E. processor. The four configurations on which the parallel algorithms are designed and implemented are summarized below. •
322
AMD Athlon cluster: a cluster of 24 nodes. Each node is an AMD Athlon dual-core processor at 2GHz, 512KB cache, with 100Mb/s Ethernet switch as the interconnection; GNU C compiler;
Cell Processing for two Scientific Computing Kernels
•
•
•
AMD Opteron single-core cluster: a cluster of 16 nodes. Each node is a dual AMD Opteron single-core processors at 2.4GHz, 2GB per node of physical memory, with Voltaire Infiniband Switched-fabric interconnection; C compiler from Portland Group. AMD Opteron dual-core shared memory machine: 8 AMD dual-core Opteron processor at 1GHz, 1M cache per core, 4GB memory per processor and 32GB distributed shared memory in the system; Sun C compiler and Omni compiler; IBM Cell/B.E. processor: Georgia Tech Cell/B.E. cluster containing 14 IBM Blade QS20 dualcell blades, each running at 3.2GHz, GNU C compiler.
Figure 1 depicts the computation time for these four configurations. There are different ways to compare the performance between pairs of configuratons. It illustrates the performance of the MPI-version parallel FDTD algorithm (Algorithm 2) on two clusters. The AMD Opteron single-core cluster outperforms the AMD Athlon cluster when the same number of processing units is used. One of the main reasons for this difference is that the two clusters use different interconnection networks between processors. The Voltaire Infiniband Switched-fabric interconnection network of the AMD Opteron single-core cluster provides faster communication speed and lowers the communication latencies and synchronization latencies. Figure 1 also shows the performance of MPI-version on the AMD Opteron signle-core cluster and the OpenMP-version on AMD Opteron dual-core shared memory machines. We notice that the AMD Opteron dual-core processor outperforms Opteron single-core processor both at the core level (1 processing unit) and at processor level (2 processing units for dual-core versus 1 processing unit for single-core). However, for 4 and 8 processing units, the homogeneous multicore architecture with Opteron dual-core processors has longer computation time than the AMD Opteron single-core cluster. The reason is the overhead of multi-threads and the longer memory latency for dual-core system. Although the singlecore Opteron processors resides on different computers, these computers are connected with Voltaire Infiniband Switched-fabric interconnection which minimize the communication latencies. The performance comparison between AMD Opteron single-core cluster and the Cell/B.E. processor is depicted in Figure 1. The Cell/B.E. uses constantly reduced time when more SPEs are involved. This implies that the performance on the Cell/B.E. processor keeps almost constant ratio of 1.45 over the AMD Figure 1. Computation time for different processors
323
Cell Processing for two Scientific Computing Kernels
Opteron single-core processors, no matter how many processing units are involved. At the processor level, a Cell/B.E. processor using 8 SPEs is 7.05 faster than an Opteron single-core processor. The final comparison is between the Cell/B.E. processor and the Opteron dual-core processors in the homogeneous multicore architecture. We can see from the figure that when more processing units are involved, the speedup of Opteron dual-core processor in the shared memory machine is lower than the speedup of the Cell/B.E. processor. This is due to the thread overheads when using more cores. At the processor level, a Cell/B.E. processor using 8 SPEs is 3.37 faster than an Opetron dual-core processor. As discussed in the previous section, DMA size may be a factor for the performance improvement since a large number of transfers incur more communication overhead. For this purpose, we designed a simulation scenario where different number of rows (each row has 600 floats, which is 2,400 bytes) in the computational domain are transferred in each DMA command. The result is depicted in Figure 2(a). The almost flat curves (downward a little for 6 rows in each DMA command) indicates that the DMA size is not a factor for FDTD since the minimal transfer size (for 1 row) is already 2400 bytes. For bigger sizes, the next DMA command has to wait for the previous transfer (large number of data, e.g. 14, 400 bytes for 6 rows) to be completed. The figure shows another issue for the communication overhead, the time for synchronization. It can be seen from the different spaces between different curves. The space between the top two curves (for 1 SPE and 2 SPEs) is the widest, while the space between the bottom two curves (for 4 SPEs and 8 SPEs) is the narrowest. The observation verifies the fact that more overhead occurs when more SPEs are involved. In fact, the speed up for 2 SPEs is 1.95, 3.69 for 4 SPEs, and 4.92 for 8 SPEs. Another scenario was designed to verify the performance difference when using signal and mailbox synchronization mechanisms. The results shown in Figure 2(b) indicate that the two mechanisms give comparatively equal performance. Based on these comparisons, we can conclude that: • •
The Cell/B.E. processor provides significant performance improvement over conventional processors and parallel architectures. All parts of the whole parallel system are important to the final performance. These include the processor, the interconnection network, and the compiler.
FFT This section explains the Fast Fourier Transform (FFT). Communication and synchronization are two main latency issues in computing FFT on parallel architectures (Loan, 1992). Both latencies have to be either hidden or tolerated to achieve high performance. One approach to achieve this is by multithreading. Another approach to tolerate latency is to map data efficiently onto the processors’ local memory and exploiting data locality. Indirect swap networks (ISN), an idea proposed in VLSI circuits can be efficiently used to compute the butterfly computations in FFT (Yeh, Parhami, Varvarigos, & Lee, 2002). Data mapping in the swap network topology reduces the communication overhead by half at each iteration. This section explains the traditional FFT Cooley-Tukey algorithm followed by the FFT algorithm based on the ISN method. The parallel FFT algorithm based on ISN is designed on the Cell/B.E. and compared to a cluster.
324
Cell Processing for two Scientific Computing Kernels
Figure 2. Performance of FDTD on Cell/B.E.
Fast Fourier Transform The discrete Fourier transform (DFT) is used in many applications such as in digital signal processing to analyze the signals frequency spectrum, to solve partial differential equations or to perform convolutions. The 1D DFT computation can be expressed as a matrix-vector multiplication. A straightforward solution for N input elements is of complexity O(N2). The Fast Fourier Transform (FFT) proposed by Cooley-Tukey is a fast algorithm for computing the DFT that reduces the complexity to O(N log N). The FFT has been studied extensively as a frequency analysis tool in diverse applications areas such as audio, signal, image processing, computed tomography and computational finance (Barua et al.,
325
Cell Processing for two Scientific Computing Kernels
2005). There are many variants of the FFT algorithm. Mathematically, all variations differ in the use of permutations and transformations of the data points (Loan, 1992). For a sequence x(r) with N data points, decimation-in-time (DIT) FFT, divides the sequence into two halves x1(r) and x2(r) at every iteration. On the other hand, decimation-in-frequency (DIF) FFT divides the sequence into odd and even data points at every iteration. The difference of division method leads to different structure of the butterfly computation. Depending on the number of groups to divide the input elements, there are radix-2, radix-4, mixed-radix, split-radix FFTs in the literature. In this chapter, we consider the basic radix-2 DIT FFT on N input complex elements where N is a power of 2. Parallelizing the FFT on multiprocessor computers concerns the mapping of data onto processors. On shared-memory processors, the whole data is placed in one global memory, allowing all processors to have access to the data. The computation is subdivided among the processors in such a way that the load is balanced and memory conflict is low. The recursive FFT algorithm can be easily programmed on such machines. On distributed architectures, each processor has its own local memory and data exchanges are via message passing. In this architecture, the recursive FFT algorithm is not the appropriate algorithm because combining even and odd parts of elements at each iteration while the data is distributed on different processors requires relatively high level of programming sophistication. Therefore, an iterative scheme of FFT is more suitable for distributed machines. There are mainly two latency issues in computing FFTs on parallel architectures: communication and synchronization. During the butterfly computation, the partners change at each iteration and an efficient data mapping is difficult. Data need to be communicated between processors at every iteration. This implies synchronization between processors. In order to achieve high performance, both these latencies have to be either hidden or tolerated. One such approach is multithreading (Thulasiraman, Theobald, Khokhar, & Gao, 2000). Another approach to tolerate latency is by mapping data efficiently onto the processors local memory, that is exploiting data locality. Yeh et al. (Yeh et al., 2002) proposed an efficient parallel architecture for FFT in VLSI circuits using indirect swap networks (ISN). Data mapping in the swap network topology reduces the communication overhead by half at each iteration. The idea of swap network has been applied to option pricing in computational finance applications (Barua et al., 2005) and has shown to produce better performance than the traditional parallel DIT FFT. However, synchronization latency is still an issue for large data size.
Cooley-Tukey Butterfly Network and ISN At each iteration of the FFT computations, two data points perform a butterfly computation. The butterfly computation can be conceptually described as follows: a and b are points or complex numbers.The upper part of the butterfly operation computes the summation of a and b with a twiddle factor ω while N N summations and differences the lower part computes the difference. In each iteration, there are 2 2 (Grama, Gupta, Kumar, & Karypis, 2003). N elements on P procesP sors, involves communication for log P iterations and terminates after log N iterations. If we assume shuffled input data at the beginning (Grama et al., 2003), the first (log N – log P) iterations require no communication. Therefore, during the first (log N – log P) iterations (local stage), a sequential FFT algorithm can be used inside each processor. At the end of the (log N – log P)th iteration, the latest In general, a parallel algorithm for FFT, with blocked data distribution of
326
Cell Processing for two Scientific Computing Kernels
N data points exist in each processor. The last log P iterations require remote P N communications (called remote stage). Note that the other half of the pairs for the elements on one P processor reside on the same remote processor. The identity of the processors for remote communication can be identified very easily. That is, at the kth stage of the remote stages ( k = 0, , log P - 1 ), if processor Pi needs to communicate with processor Pj then j = iXOR2k where XOR is exclusive OR binary operation (Chu & George, 2000; Grama et al., 2003). N Note that in the Cooley-Tukey FFT algorithm, data elements are exchanged between two paired P processors without inter-processor permutation at the remote stage, leaving each paired processors with 2N the same copy of elements for butterfly computations. Since the same butterfly computations are P performed on the processors, there are redundant computations. If only one processor performs the butcomputed values for
terfly computations, then some of the processors may be idle. Furthermore, this communication incurs N elements at each stage for remote stages and the distance each message trava message overhead of P els increases as iterations move forward depending on the interconnection network. The consequence is that more communication and synchronization overhead leads to traffic congestion in the butterfly network. One solution to reduce data communication at each remote stage is through inter-processor permutation by using Indirect Swap Network (ISN) (Yeh et al., 2002). For local stages, each processor permutes N N elements locally and performs butterfly calculations; for remote stages, each processor permutes 2P 2P N and exchanges data with its paired processor. Note that the permutation exploits data locality and 2P N thereby reducing message overhead between two paired processors by . This is a significant decrease 2P in communication for very large networks. An indirect swap network is depicted in Figure 3 for 16 elements on 4 processors. In this example, at remote stage 0, processors 0 and 1 exchange data points 2, 3 and 4,5 respectively. The other data points are kept intact in their respective processors (data points 0 and 1 in processor 0, data points 6 and 7 in processor 1). In general for a given N and P processors, N data points are swapped between two processors. The result is reducing the communication of the 2P traditional butterfly network by half.
Parallel FFT Based on ISN on Cell/B.E. As a new architecture for high performance computing, Cell/B.E. has been investigated for different FFT algorithms. Chow et al. (Chow, Gossum, & Brokenshire, 2005) investigate the performance of Cell/B.E. for a modified stride-by-1 algorithm proposed by Bailey based on Stockham Self-sorting FFT. They fix the input sampling size to 16 million (224) single precision complex elements and achieve 46.8 Gflop/s on a 3.2GHz Cell/B.E.. Williams et al. (Williams et al., 2006) investigate 1D/2D FFT on Cell/B.E. on one SPE. Bader et al. (Bader & Agarwal, 2007) investigate an iterative out-of-place DIF FFT with 1K to 16K complex input samples and obtain a single precision performance of 18.6Gflop/s. Their approach incurs frequent synchronization overhead both at the end of the butterfly update and at the end of the
327
Cell Processing for two Scientific Computing Kernels
Figure 3. Indirect swap network with bit-reversed input and scrambled output
followed permutations. FFTW adds various benchmarks of FFT on IBM Cell Blade and PlayStation 3 for different combination among single precision, double precision, real number inputs, complex number inputs, 1D, 2D, and 3D transforms. In the implementation of the FFT algorithm on the Cell/B.E., assume N is the size of the data and P is the number of SPEs. The PPE bit-reverses input data which is naturally ordered. The PPE prepares and conveys information such as the memory address of the bit-reversed data, the memory address of the swap area, the number of SPEs, and the problem size when creating SPE threads. After SPEs receive the information, each of them gets the corresponding ( N ) amount of data from the main memory acP cording to their id. At the same time, SPE can overlap the communication between the main memory and LS with the task of computing twiddle factors. Each SPE then starts (log N – log P) iterations of the sequential computation. After (log N – log P) iterations, each of the SPEs starts the iterations of the remote stage. At every iteration of the remote stage, each SPE stores intermediate results back to the swap area and synchronizes to ensure every SPE stores their portion of intermediate results to the swap area. At the end of synchronization, each SPE gets their paired partners from the swap area to perform N data is stored back for each SPE at each the butterfly computation. Note that in the swap network, 2P iteration. In the Cell/B.E. implementation, the SPEs do not exchange data directly with one another, which is different from the distributed algorithm implementation. In a cluster, the data is initially distributed to the processors by the master processor, and the processors communicate with one another to obtain
328
Cell Processing for two Scientific Computing Kernels
N communications, which is an overhead in the 2P distributed implementation. On the Cell/B.E., data exchange is between the SPE and main memory via asynchronous DMA transfer issued by SPE. This is a significant advantage on the Cell/B.E. over distributed memory machines. The EIB is fast and allows fast communication between the main memory and SPEs. On the distributed memory machines, the interconnection network plays a crucial role in the exchange of data between processors. On the Cell/B.E., since it is system-on-chip architecture, DMA access is fast, and every element works together to accomplish the task. Another issue is synchronization. On the distributed memory machines, the processors synchronize at each iteration. In the FFT implementation on Cell/B.E., the SPEs also need to synchronize, but some unique features of the Cell/B.E. bring great benefits to FFT computations. As shown in section 0, two synchronization mechanisms, mailbox and SPE signal notification registers, are used for FFT. At the end of all iterations, the SPEs write the final results back to the main memory. This new FFT algorithm based on ISN for Cell/B.E. is presented as a pseudo-code in Algorithm 6. It only shows the workload on the SPE. The PPE is responsible to bit-reverse the naturally-ordered input at the beginning and shuffle the final computation results of SPEs such that the overall output is naturally-ordered as in butterfly network. Algorithm 6 Parallel FFT based on ISN for Cell on SPE their paired partners at each iteration. This requires
Input:N/P bit-reversed single precision complex number in array A[N/P ], P SPEs, N = 2i;P = 2j;N >> P, array B[N/P ] to store transferred data temporarily Output: scrambled N/P complex numbers transformed in array A DMA in N/P complex numbers to array A; Compute twiddle factors and stored in array W[N/2]; fori = 0 to (logN - logP - 1) do NG = 2i; {number of groups} shuffle twiddle factors W[N/2]; forj = 0 to N/P- 1 step 2 doif ((j&NG) = 0) then pID = j xor NG; {butterfly partner id} Copy A[j] and A[pID] to B[j] and B[j+1]; else pID = (j + 1) xor NG; Copy A[pID] and A[j+1] to B[j] and B[j+1]; end if end for whileUTE > 8 do{UTE: un-transformed elements number} SIMDize butterfly computation between neighboring 8 elements in array B; UTE- = 8; end while Compute any un-transferred elements if N/P is not multiple of 8; Swap results in array B to array A; end for fori = 0 to (logP - 1) doif ((SPEid & NG) = 0) then DMA out all N/2P elements with odd number indices to main memory;
329
Cell Processing for two Scientific Computing Kernels
else DMA out all N=2P elements with even number indices to main memory; end if Synchronize with all other SPEs; if ((SPEid & NG) = 0) then DMA in N/2P elements from main memory and put into the odd number indexed positions; else DMA in N/2P elements from main memory and put into the even number indexed positions; end if NG = 2i; shuffle twiddle factors W[N=2]; whileUTE > 8 do SIMDize butterfly computation between neighboring 8 elements in array B; UTE- = 8; end while Compute any un-transferred elements if N/P is not multiple of 8; Swap results in array B to array A; end for DMA out final N/P transformed results in array A to PPE;
Experimental Results The new FFT algorithm based on swap network was implemented using sdk2.1 on an IBM Blade QS20 dual-Cell blade running at 3.2GHz available at Georgia Institute of Technology. The compiler is xlc compiler. Figure 4 shows the performance of the algorithm for different problem sizes on different numbers of SPEs. The figure shows that the execution time decreases when increasing number of SPEs for different input sizes. Furthermore, the time for 4K input decreases faster than the time for 1K when increasing number of SPEs. This is because DMA supports up to 16K asynchronous transfers between main memory and local store. Therefore, for larger problem size, the communication overhead is very close to the overhead of smaller problem size. The difference between run time for larger problem size and smaller problem size is mainly the computation time on each SPE. In order to investigate features of Cell/B.E., we compare the execution time of the algorithm on Cell/B.E. with its execution time on a cluster (Barua et al., 2005). The cluster is a 20 node SunFire 6800 running MPI. The SunFire system consists of Ultra Space III CPUs, with 1050 MHz clock rate and 40 gigabytes of cumulative shared memory running Solaris 8 operating system. The comparison is depicted in Figure 5(a) for 16K single precision complex numbers. As shown in the figure, Cell/B.E. performs much better than the cluster. For 8 SPEs on Cell/B.E. and for 8 processors of the cluster, Cell/B.E. is 6.4 times faster than the cluster for 16K input data size. The reason is due to the large communication N ´ log P communications per processor for log P iterations. On the overhead in the cluster, that is, 2P
330
Cell Processing for two Scientific Computing Kernels
Figure 4. Computation time for different problem size on different number of SPEs
contrary, the high-speed EIB on Cell/B.E., which supports a peak bandwidth of 204.8GBytes/s for intrachip transfers, provides good performance for Cell/B.E., especially when the problem size increases. This can be further validated by Figure 5(b). The FFT algorithm for Cell/B.E. outperforms the FFT algorithm for the traditional cluster significantly for larger problem sizes. Note that the communication between the main memory and the SPEs do not degrade the performance of the algorithm. This is part due to the system on chip architecture of Cell/B.E.. The interconnection network which is a hindrance on distributed memory machines is not of concern on Cell/B.E. We have used the high speed EIB, asynchronous DMA transfer overlapped with computation, large number of large uniform registers for SIMD operations available on the Cell/B.E. to our advantage in the FFT implementation. This is our initial work on FFT. We hope to compare our algorithm and results on Cell/B.E. with other existing FFT algorithms and their results on Cell/B.E., such as FFTW and FFTC.
CONCLUSION Although many scientific computing applications have achieved great performance improvement via different parallel paradigms, they are limited for further upgrade because of the three walls posed on the conventional processors. In this chapter, we have focused on multicore processors, especially Cell/B.E., which aims to tackle the three walls to provide significant performance improvement via novice features such as ultra high speed on-chip bus EIB, eight SIMD coprocessor SPEs, software managed memory hierarchy and hardware support of asynchronous communication between hierarchical memories. However, the novelty brings challenges for parallel algorithm design. Therefore, we have investigated two scientific computing kernels, FDTD and FFT, as case studies to illustrate the challenges and
331
Cell Processing for two Scientific Computing Kernels
Figure 5. Comparison between Cell/B.E. and cluster
solutions when designing parallel algorithms on Cell/B.E.. For 2D FDTD, we have achieved an overall speedup of 14.14 over AMD Athlon running at 2GHz and 7.05 over AMD Opteron running at 2.4GHz at the processor level for a computational domain of 600 × 600 Yee cells. As to 1D FFT, for 8 SPEs of IBM Blade QS20 dual-Cell blade running at 3.2GHz and for 8 processors of the cluster of SunFire 6800 running at 1050MHz clock rate, Cell/B.E. is 3.7 times faster than the cluster for 4K input data size and 6.4 times faster than the cluster for 16K input data size. The results obtained from these problems are promising to further consider Cell/B.E. as high performance comptung architecture for many more
332
Cell Processing for two Scientific Computing Kernels
applications. I is not difficult to see that Cell/B.E., especially its eight independent SPEs, brings great performance improvement via manual SIMD operations, explicit data movement management by asynchronous DMA transfers and explicit scheduling and synchronization (such as multiple buffering) among all nine cores. However, all the performance improvement techniques put more burdens on developers compared to coventional processors, which in turn impacts the productivity and code portability. Therefore, developers have to balance between productivity and performance (a metric called relative productivity), which can be measured by the ratio of speedup over SLOC (source lines of code) (Alam S. R., Meredith J. S., Vetter J. S., 2007). With the popularity of multi-core architectures, the industry and the academia have been improving the productivity from multi-core architectures by enhancing the software stacks such as the optimized compiler, optimized library, and different programming models and development platforms. These enhancements will help developers on multi-core architectures, including Cell/B.E., fully unleash the power of multi-core without introducing too much programming complexities, thus achieving high relative productivity.
ACKNOWLEDGMENT The authors are thankful to the University of Manitoba Research Grants Program for their support in this research. The authors would also like to acknowledge the partial financial support from Natural Sciences and Engineering Research Council (NSERC) of Canada. The authors acknowledge Georgia Institute of Technology, its Sony-Toshiba-IBM Center of Competence, and the National Science Foundation, for the use of Cell Broadband Engine resources that have contributed to this research.
REFERENCES Alam, S. R., Meredith, J. S., & Vetter, J. S. (2007, Sept.) Balancing productivity and performance on the cell broandband engine. IEEE Annual International Conference on Cluster Computing. Asanovic, K., Bodik, R., Catanzaro, B. C., Gebis, J. J., Husbands, R., Keutzer, K., et al. (2006, Dec). The Landscape of Parallel Computing Research: A View from Berkeley (Tech. Rep. No. UCB/EECS2006-183). EECS Department, University of California, Berkeley. Bader, D. A., & Agarwal, V. (2007, Dec). FFTC: Fastest fourier transform on the ibm cell broadband engine. In 14th IEEE international conference on high performance computing (hipc 2007) Goa, India, (pp. 18–21). Barua, S., Thulasiram, R. K., & Thulasiraman, P. (2005, Aug.). High performance computing for a financial application using fast Fourier transform. In Euro-par parallel processing (p. 1246-1253). Lisbon, Portugal. Chen, T., Raghavan, R., Dale, J. N., & Iwata, E. (2007, Sept.). Cell Broadband Engine Architecture and its first implementation-A performance view. IBM. Journal of Research and Development (Srinagar), 51(5), 559–572.
333
Cell Processing for two Scientific Computing Kernels
Chow, A. C., Gossum, G. C., & Brokenshire, D. A. (2005). A programming example: Large fft on the cell broadband engine. In Gspx. tech. conf. proc. of the global signal processing expo. Chu, E., & George, A. (2000). Inside the fft black box: Serial and parallel fast Fourier transform algorithms. Boca Raton, FL: CRC Press LLC. Grama, A., Gupta, A., Kumar, V., & Karypis, G. (2003). Introduction to parallel computing. Upper Saddle River, NJ: Pearson Education Limited. Guiffaut, C., & Mahdjoubi, K. (2001, April). A Parallel FDTD Algorithm Using the MPI Library. IEEE Antennas andPropagation Magazine, 43(No. 2), 94–103. Liu, L.-L., Liu, Q., Natsev, A., Ross, K. A., Smith, J. R., & Varbanescu, A. L. (2007, July). Digital media indexing on the cell processor. In 16th international conference on parallel architecture and compilation techniques, Beijing, China (pp. 425–425). Loan, C. V. (1992). Computational frameworks for the fast Fourier transform. Philadelphia, PA: Society for Industrial and Applied Mathematics. Su, M. EI-kady, I., Bader, D. A., & Lin, S. (2004, August). A Novel FDTD Application Featuring OpenMP-MPI Hybrid Parallelization. In 33rd international conference on parallel processing(icpp) Montreal, Canada, (pp. pp. 373–379). Taflove, A., & Hagness, S. (2000). Computational Electrodynimics: The Finite-Difference Time-Domain Method, second edition. Boston: Artech House. Thulasiram, R. K., & Thulasiraman, P. (2003, August). Performance evaluation of a multithreaded fast fourier transform algorithm for derivative pricing. [TJS]. The Journal of Supercomputing, 26(1), 43–58. doi:10.1023/A:1024464001273doi:10.1023/A:1024464001273 Thulasiraman, P., Khokhar, A., Heber, G., & Gao, G. (2004, Jan.). A fine-grain load adaptive algorithm of the 2d discrete wavelet transform for multithreaded architectures. [JPDC]. Journal of Parallel and Distributed Computing, 64(1), 68–78. doi:10.1016/j.jpdc.2003.06.003doi:10.1016/j.jpdc.2003.06.003 Thulasiraman, P., Theobald, K. B., Khokhar, A. A., & Gao, G. R. (2000, July). Multithreaded algorithms for the fast Fourier transform. In Acm symposium on parallel algorithms and architectures Winnipeg, Canada, (p. 176-185). Williams, S., Shalf, J., Oliker, L., Kamil, S., Husbands, P., & Yelick, K. (2006, May). The Potential of the Cell Processor for Scientific Computing. In Computing frontiers (cf’06) Ischia, Italy (pp. 9–20). Xu, M., Sabouni, A., Thulasiraman, P., Noghanian, S., & Pistorius, S. (2007, Sept.). Image Reconstruction using Microwave Tomography for Breast Cancer Detection on Distributed Memory Machine. In International conference on parallel processing (icpp) XiAn, China (p. 1-8). Yee, K. (1966, May). Numerial solution of initial boundary value problems involving maxwell’s equations in isotropic media. IEEE Transactions on Antennas and Propagation, AP-14(8), 302–307.
334
Cell Processing for two Scientific Computing Kernels
Yeh, C.-H., Parhami, B., Varvarigos, E. A., & Lee, H. (2002, July). VLSI layout and packaging of butterfly networks. In Acm symposium on parallel algorithms and architectures Winnipeg, Canada (pp. 196–205). Yu, W., Mittra, R., Su, T., Liu, Y., & Yang, X. (2006). Parallel Finite-Difference Time-Domain Method. Boston: Artech House publishers.
KEY TERMS AND DEFINITIONS Cell Broadband Engine Architecture: Cell Broadband Engine Architecture, also abbreviated CBEA or Cell/B.E. or called Cell as a shorthand, is a microprocessor architecture jointly developed by Sony, Toshiba, and IBM. It is a heterogeneous multi-core architecture by combining one general-purpose Power architecture core PPE (Power Processor Element) with eight streamline coprocessing elements SPEs (Synergistic Processor Elements). PPE supports the operating system and is mainly used for control tasks. SPEs support SIMD (Single Instruction Multiple Data) processing. Each SPE has 128 entries 128-bit registers and 256KB local memory (called local storage) both for instructions and data. The PPE, SPEs and memory subsystem are connected by on-chip bus Element Interconnect Bus (EIB). Cell is designed as a general-purpose high-performance processor to bridge the gap between conventional desktop processors and more specialized high-performance processors. It has been installed in Sony PlayStation 3. Cooley-Tukey FFT Algorithm: The Cooley-Tukey algorithm, named after J.W. Cooley and John Tukey, is the most common FFT algorithm. It re-express the DFT of an arbitrary composite size N = N1N2 in terms of smaller DFTs of size N1 and N2, recursively, in order to reduce the computation time to O(N logN). Discrete Fourier Transform: Discrete Fourier transform (DFT) is one of the specific forms of Fourier analysis which transforms one function in the time domain into another function in the frequency domain. A DFT decomposes a sequence of values into components of different frequencies. A direct way to compute a DFT of N points takes O(N2) arithmetical operations. The inverse DFT (IDFT) transforms one function in the frequency domain into another function in the time domain. Fast Fourier Transform: Fast Fourier Transform (FFT) is an efficient algorithm to compute the DFT and its inverse. Instead of O(N2) arithmetical operations in a direct way to compute a DFT of N points, FFT can compute the same result in only O(N logN) operations. Finite Difference Time Domain: Finite Difference Time Domain (FDTD) is a numerical technique proposed by Yee in 1966 to solve Maxwell’s equations in electromagentics fields. It discretizes a 3D field into a mesh of cubic cells or a 2D field into a grid of rectangular cells using central-difference approximations. It is a time-stepping algorithm. Each cell has electrical field vector components and magnetic field vector components which are updated at alternate half time steps in a leapfrog scheme in time. Indirect Swap Network: Indirect Swap Network (ISN) is an improvement to the Cooley-Tukey butterfly network. It aims to reduce data communication by half than traditional Cooley-Tukey network by introducing inter-processor permutation when implemented on parallel systems using message passing model. Multi-Core Processor: A multi-core processor combines two or more independent cores (normally a CPU) into a single package composed of a single die, or more dies packaged together. It is also called
335
Cell Processing for two Scientific Computing Kernels
chip-level multiprocessor (CMP) and implements multiprocessing in a signle physical package. If the cores are identical, the processor is called homogeneous multi-core processor, such as AMD Opteron dual-core processor. If the cores are not the same, the processor is called heterogeneous multi-core processor, such as Cell/B.E. processor. Single Instruction Multiple Data: Single Instruction Multiple Data (SIMD) is a technique used to achieve data level parallelism, the same instruction applied to multiple data. It is one category of processor architecture proposed in Flynn’s taxonomy. SIMD was popular in large-scale supercomputers with vector processors. Now, smaller-scale SIMD operations have become widespread in general-purpose computers, such as SSE instructions in regular Intel processors and SIMD instruction set in Cell/B.E. processors.
336
Section 4
Scheduling and Communication Techniques
338
Chapter 15
On Application Behavior Extraction and Prediction to Support and Improve Process Scheduling Decisions Evgueni Dodonov University of São Paulo – ICMC, Brazil Rodrigo Fernandes de Mello University of São Paulo – ICMC, Brazil
ABSTRACT The knowledge of application behavior allows predicting their expected workload and future operations. Such knowledge can be used to support, improve and optimize scheduling decisions by distributing data accesses and minimizing communication overheads. Different techniques can be used to obtain such knowledge, varying from simple source code analysis, sequential access pattern extraction, history-based approaches and on-line behavior extraction methods. The extracted behavior can be later classified into different groups, representing process execution states, and then used to predict future process events. This chapter describes different approaches, strategies and methods for application behavior extraction and classification, and also how this information can be used to predict new events, focusing on distributed process scheduling.
INTRODUCTION The knowledge of the application behavior allows predicting the application workload during its execution and forecasting distributed data accesses. In order to obtain such data, different strategies can be employed, varying from simple source code analysis, sequential access pattern extraction (Kotz & Ellis, 1993), history-based approaches (Gibbons, 1997; Smith, Foster & Taylor, 1998) and on-line behavior extraction methods (Senger, Mello, Santana, & Santana, 2005; Dodonov, Mello, & Yang, 2006). It is possible to define two different strategies for application behavior extraction. The first approach DOI: 10.4018/978-1-60566-661-7.ch015
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
On Application Behavior Extraction and Prediction
consists of a static source code evaluation, where the behavior is evaluated in an empiric way, without real application execution. The second, also known as dynamic evaluation, consists of the application behavior evaluation during execution. The static evaluation approach is elderly, being conceived by Church and Turing, and is well described by Fischer (1965). Originally, the technique was applied to finite state automata and Turing machines, aiming at detecting possible problems which could lead to deadlock states or improper application terminations. With the evolution of computing systems, new static evaluation techniques were introduced. Among those techniques are the model verification method, which aims at reducing the application behavior to a formal representation (Schuster, 2003), and the abstract interpretation method (Loiseaux, Graf, Sifakis, Bouajjani, & Bensalem, 1995), which represents the application behavior using a series of finite state machines, characterizing different application behavior using independent automata states. Dynamic behavior evaluation technique, on its turn, investigates the behavior during process execution, usually with aid of debugging or monitoring utilities. It can be further divided into continuous monitoring and event-based approaches (Jain, 1991). Continuous monitoring techniques consist of periodic extraction of application characteristics, determining the current behavior by evaluating differences among each execution state. This technique can be easily employed, as no application modification is required. However, as the monitoring occurs on pre-determined intervals, it introduces a constant overhead. Besides, a disadvantage of this approach lies in its impreciseness – as the monitoring occurs on fixed intervals, it is not possible to determine the precise behavior on specific execution states. The event-based technique evaluates the behavior by determining critical execution states and extracting application characteristics when such states are reached, resulting in a more precise behavior determination. The adoption of this technique is more difficult, as it requires previous knowledge of application functionalities in order to correctly determine critical execution states that are further used to extract its behavior. Besides, this approach usually requires source code instrumentation or the interception and interpretation of function calls. Among the advantages of event-based approach is the lower execution overhead, as the behavior is only extracted on specific execution points (for example, on data transfers, or thread synchronization operations). The area of behavior prediction has received a lot of attention over the last years, resulting in a series of comparisons among different approaches, motivating competitions such as the K. U. Leuven (Suykens & Vandewalle, 2000), Eunite (Chen, Chang, & Lin, 2004) and Santa Fe (Weigend & Gershenfeld, 1994). However, most of the researches are focused on generic chaotic time-series prediction, or posterior behavior reconstruction. The study on the applicability of behavior prediction techniques to support and improve the performance of distributed systems, combined with our previous researches in this field, has motivated us to write this chapter, aiming at outlining different approaches and strategies employed on the process behavior extraction, classification and prediction, and their usage in distributed scheduling, load balancing and data access anticipation. This chapter is organized as follows: Section 2 overviews the evolution of application behavior extraction strategies. Section 3 describes different approaches and techniques for behavior classification and prediction, and Section 4 outlines practical applications of the prediction results in distributed environments. Finally, Section 5 summarizes this chapter.
339
On Application Behavior Extraction and Prediction
BACKGROUND: BEHAVIOR ExTRACTION APPROACHES One of the most common tasks for static application behavior evaluation is the source code analysis. The most common approaches rely on widely available tools - such as grep, find and sed (Wilding & Behman, 2005). It is also possible to use specific source code indexation applications, such as LXR (http:// lxr.sourceforge.net) and similar tools, or code documentation-oriented approaches, such as ones of Java Docs or Doxygen (http://www.doxygen.org). Application behavior can also be evaluated by specific tools, such as Lint, Blast and Valgrind (Nethercote & Fitzhardinge, 2004), that allow to extract and profile the application behavior aiming at identifying possible faults during execution (such as incorrect parameter casting, bad memory usage and unreachable code). Those approaches, however, rely on the availability of application source code. In cases where the code is not available, other techniques can be employed. One of such techniques is known as tracing, which consists in the extraction and further analysis of system calls performed by the application. Generally, the system kernel provides support to trace such operations, usually via the ptrace system call, which notifies the kernel that the application is being monitored. In this case, it is possible to trace application operations in a completely transparent way. As examples of applications that rely on system call tracing, we may mention strace (http://strace.sourceforge.net) and GridBox (Dodonov, Souza, & Guardia, 2004) projects. The ptrace approach allows modifying and retrieving additional information for each system call, being widely used for system and application monitoring and debugging. However, as the call tracing occurs on the kernel level, it is difficult to intercept high-level functions. When such functionality is required, dynamic system linker-related techniques can be used, such as specific environment variables used by Linux linker (ld.so), or a tracing application like ltrace (Wilding & Behman, 2005). This approach allows intercepting any function call and tracing or modifying it when required, as demonstrated by the GridBox (Dodonov et al., 2004) and MidHPC (Andrade Filho et al., 2008) projects. Continuous monitoring-based approaches, on their turn, are more widely used as they do not require knowledge of application functionality. Such methods usually rely on periodical system statistics collecting and analysis, either on the user level, as in the StatMonitor (Keskar & Leibowitz, 2005; Dodonov et al., 2006), or on the kernel level (Senger et al., 2005). Furthermore, application-specific techniques can be employed when using a pre-defined execution environment, such as MPI, as demonstrated next.
MPI Application Behavior Extraction One of the most widely parallel programming technique is the MPI (Message Passing Interface) standard (Gropp, Lusk, Doss, & Skjellum, 1996; Squyres & Lumsdaine, 2003). This approach provides a mechanism for transparent message passing among distributed nodes, allowing synchronous and asynchronous data transfers in a distributed environment. The most widely used MPI implementations are MPICH (Gropp et al, 1996) and LAM-MPI (Squyres & Lumsdaine, 2003). Among other implementations are the Intel MPI Library (http://intel.com/go/mpi), originally known as Vampir (Nagel, Arnold, Weber, Hoppe, & Solchenbach, 1996), and the recently introduced Open-MPI (Gabriel et al., 2004). Initially, MPI was intended to be used in cluster environments, composed of homogeneous nodes
340
On Application Behavior Extraction and Prediction
and without fault tolerance mechanisms. However, with the evolution of distributed environments, such approaches became a clear disadvantage, being inadequate for heterogeneous and large scale systems. This lead to the introduction of new MPI versions, focused on large heterogeneous distributed environments such as computational grids, with approaches such as the GRID-MPI project (Ishikawa, Matsuda, Kudoh, Tezuka, & Sekiguchi, 2003). Since the MPI standard is implemented in the form of a library, the application debugging and monitoring requires specific libraries or tools to obtain the behavior information, such as the Xmpi utility, included in most of the MPI distributions. Specific MPI profiling and monitoring utilities are also widely used, such as the Intel Trace Tools (ITT), included in the Intel MPI library, which allow both continuous and event-based evaluation of distributed MPI applications. The ITT applications provide support for controlled execution, application tracing, flow control and communication pattern visualization among nodes, being divided into two main applications: Intel Trace Collector, used for on-line application behavior collection, and Intel Trace Analyzer, which evaluates the obtained data. The monitoring and behavior extraction is carried out using a shared library, dynamically linked to a MPI application. The data is stored in a consistent way, and is further evaluated by Intel Trace Analyzer. It is also possible to instrument source code of an application using specific functions to define, in a precise manner, which data should be captured. A similar approach is used in MPE (Multi Processing Environment) system, composed of a series of libraries, applications and graphical utilities for performance evaluation of MPI applications (Chan, Gropp, & Lusk, 2003). The system employs an event-based approach, providing libraries for MPI event tracing, similar to Intel Trace Tools, and a graphical analysis tool. MPE, unlike Intel Trace Tools, is freely available. A similar strategy is used by the Instrumentation Library for MPI (MPICL), which provides an API to profile and instrument the MPI applications (Huband & McDonald, 2001). However, it requires manual source code modifications. Besides such tools, mpiP utility may also be mentioned, as it provides a lightweight and scalable performance analysis library for MPI applications (mpiP: Lightweight, Scalable MPI Profiling, http://mpip.sourceforge.net). Finally, a dynamic monitoring approach is introduced by Dodonov et al. (2006), which aims at extracting and predicting MPI operations by transparently intercepting function calls during the application execution.
Distributed Application Behavior Extraction The extracted process behavior can be classified and analyzed using stochastic techniques (Devarakonda & Iyer, 1989; Feitelson, Rudolph, Schweigelshohn, Sevcik & Wong, 1997), processing of historical traces (Gibbons, 1997; Smith et al., 1998), on-line evaluation algorithms (Arpaci-Dusseau, Cutler & Mainwaring, 1998; Silva & Scherson, 2000), and mixed approaches (Senger et al., 2005, Dodonov et al., 2006). Devarakonda and Iyer (1989) proposed a statistic approach to predict CPU resource usage, input/ output operations and application memory utilization, using a clustering algorithm based on k-means combined with the Markov chains approach. This strategy allows to evaluate the behavior and identify resource-intensive applications.
341
On Application Behavior Extraction and Prediction
A similar approach is proposed by Feitelson et al. (1997), where the same application is repeatedly executed and its behavior variations evaluated. The authors observed small differences between different executions, therefore allowing to employ previously observed application functional parameters to determine the future behavior without explicit user cooperation or application modification. Approaches based on application execution are studied by several authors (Gibbons, 1997; Smith et al., 1998), who evaluate the average CPU load, memory usage and input/output operations. The derived results are further used to predict application behavior. Distributed memory accesses can also be evaluated using series of execution traces, as demonstrated by Fang et al. (2004). Similar approaches are also employed in distributed memory systems, for nonsequential data access pattern prediction, as discussed by Bianchini, Pinto and Amorim (1998). Complex data access patterns can be determined using semantic structures and analytical approaches (Lei & Duchamp, 1997), data access classification (Mehrotra & Harrison, 1999), and stochastic approaches such as hidden Markov chains model (Madhyastha & Reed, 1997). On-line process behavior prediction approaches are studied by Silva and Scherson (1997), using Bayes model and fuzzy logic to model application behavior. Similar approaches are discussed by ArpaciDusseau et al. (1998) and Corbalan, Martorell and Labarta (2001), using the collected information to control a dynamic load balancing mechanism. Finally, approaches based on artificial intelligence techniques for on-line behavior classification and prediction are studied by Senger, Mello and Dodonov (Senger, 2004; Senger et al., 2005; Mello, Senger & Yang, 2005; Dodonov et al., 2006; Dodonov & Mello, 2007). Those works employ neural networks to classify and predict the process behavior. Prediction results are further used for dynamic load balancing and scheduling algorithms (Mello & Senger, 2004), and for data prefetching (Dodonov et al., 2006). The approaches introduced in this section allow extracting and representing the behavior of distributed applications. However, the resulting data must be processed in order to be useful for future behavior prediction, as it will be shown in the next section.
APPROACHES FOR APPLICATION BEHAVIOR CLASSIFICATION AND PREDICTION The application behavior classification technique aims at reducing repetitive or similar events to a series of representative patterns, which can further be used to predict or forecast future events. It is possible to use data extracted from application behavior. However, this approach results in a huge amount of repetitive and similar data, which could compromise the prediction process. In this context, classification techniques can be used to reduce the dimensionality of data, grouping similar behaviors and performing predictions over the most relevant points. The classification is also particularly useful in cases where similarities among observed behavior cannot be trivially detected. The classification can be performed with aid of stochastic techniques, such as the iterative clustering, linear classification or auto-regressive approaches; or with the aid of artificial intelligence techniques as neural networks and evolutionary computing. The iterative clustering technique is represented by the k-means, fuzzy c-means and quality threshold (qt) clustering models. The k-means technique intends to separate the input space into different clusters, by determining a centroid value which minimizes the classification quadratic error (Bradley, Fayyad, & Reina, 1998). The fuzzy c-means approach modifies the k-means model by calculating the similarity
342
On Application Behavior Extraction and Prediction
degree among all clusters (Liao, Celmins, & Robert J. Hammell, 2003), and the qt clustering improves both k- and c-means strategies by automatically calculating the ideal number of clusters (Jiang, Tang, & Zhang, 2004). Another classification strategy is used by linear classification techniques, also known as the maximum margin classifiers, such as the Support Vector Machines (SVM) (Schölkopf & Smola, 2001). Such technique maps the input patterns, represented by a multi-dimensional weight vector, into a higher degree space by constructing a series of hyperplanes to maximize the separation of patterns from each other. The larger is the distance among the planes, the higher is the separation degree and, consequently, the better is the generalization. This approach can also be used to predict future patterns, as demonstrated by Hirose et al. (Hirose, Shimizu, Kanai, Kuroda, & Noguchi, 2007), where it is employed on the prediction of long disordered sequences. Model-based behavior prediction is also used in different stochastic auto-regressive approaches, such as: SVCA, which employs non-linear auto-regression; NARX and ARMAX models, intended to predict time series with independent variables; and ARMA and ARIMA models, used for general time series prediction (Jain, 1991). Self-Organized Maps, or SOM networks, originally introduced by Kohonen (Kaski & Oja, 1999), are frequently used for input data generalization according to similarities among them. SOM uses an unsupervised learning model, where the best matching neuron represents similar patterns, which are determined by distributing all the input values over a map and evaluating distances among them. In this process, the neuron with the closest weight to input value is declared the winner, and has its weight is adjusted towards the input value. The weights of the other neurons in its neighborhood are also adjusted, according to their distance to the winning neuron. Although the self-organized maps provide unsupervised pattern classification and feature extraction, their efficiency is limited by the need of a previous definition of network topology. Aiming at a more flexible pattern classification, self-expansible neural networks were introduced (Kunze & Steffens, 1995; Fritzke, 1995; Thacker, Abraham & Courtney, 1997), such as Cascade-Correlation Learning Architecture (CCLA), Growing Cell Structure (GCS), Probabilistic GCS, Growing Neural Gas (GNG), Growing Self-Organizing Maps, Restricted Coloumb Energy (RCE) and Contextual Layered Associative Memory (CLAM). The basic training and classification process of self-expansible networks is similar to self-organized maps. However, the self-expansible networks create new elements on demand, according to the variations among the input patterns, aiming at reducing the global residual training error by supporting the neuron with highest accumulated error rate. The creation of new elements is periodical and requires several previous training phases, therefore limiting the networks capabilities for on-line classification. The introduction of novelty-detection networks, such as GWR (Marsland et al., 2002) and SONDE (Albertini & Mello, 2007), further extended the family of adaptive data classification approaches. Such networks provide additional advantages, creating new neurons at any time and forgetting irrelevant information, what may result in a more precise and efficient pattern classification for temporal applications. A different approach is employed by the Adaptive Resonance Theory (ART) family of neural networks, proposed by Grossberg (Carpenter & Grossberg, 1987). The basic ART system is an unsupervised learning model and typically consists of neuron layers for comparison and recognition, a vigilance parameter, and a reset module. The comparison and recognition layers are responsible for similarity determination among input values, and their classification. The vigilance parameter has considerable influence in the
343
On Application Behavior Extraction and Prediction
classification: the higher is the vigilance parameter, the more accurate is the classification, although such accuracy implies in lost of generalization. Finally, the reset module is used to control the algorithm, constantly verifying the classification precision according to the vigilance parameter. In order to determine the adequate number of clusters, the resulting classification can be evaluated to determine the inter-cluster and intra-cluster distance, as proposed by Mello et al. (2005). The average distance among clusters is known as inter-cluster distance, and the distance among elements of the same cluster as intra-cluster distance. Those parameters determine the level of independence among the classified data, allowing tuning the desired generalization. The original version of ART network is known as ART-1, and was limited to the classification of binary data. In order to allow the classification of continuous input values, an extension of the network was proposed, called ART-2. Further performance optimizations of the ART-2 network resulted in ART2A network (He, Tan & Tan, 2004).Among other modifications of ART family are Fuzzy ART, which employs fuzzy logic to reduce the number of clusters created during classification; ART-3 network that allows partial neuron inhibition using a neuro-transmitting mechanism; ARTMAP or Predictive ART, which combines ART-1 and ART-2 network into a supervised learning structure, among others (Marinai, Gori, & Soda, 2005). A different approach is used in the Independent Component Analysis (ICA) family of networks which allows extracting a series of independent signals from a composite one by detecting the correlation among them. Applied to process behavior classification, such networks can be used to determine and separate different behaviors of a process. Among different ICA network implementations are Infomax, FastICA and MF-ICA (Rosca, Erdogmus, Príncipe & Haykin, 2006). A different classification and prediction model is used by the Radial Basis Function (RBF) networks (Powell, 1987), which calculate a regressive function to represent the input patterns. This is performed by combining a series of Gaussian functions, whose combination results in regressive equation which describes the observed behavior. Among notable extensions to the RBF network are the Recurrent RBF, described by Zemouri et al. (2003), where it is used to predict chaotic time series, and Time-Delay RBF (Berthold, 1994), employed on temporal behavior recognition. The concept of interconnections among neurons with constant feedback and back-propagation techniques is used in the Multi-Layer Perceptron (MLP) neural network (Hornik, Stinchcombe & White, 1989). This allows the network to learn and adapt itself to the input patterns. Another approach is employed in the Time-Delay Neural Networks (TDNN), introduced by Waibel et al. (1989), and used for position-independent recognition of features within a larger pattern. While in a traditional neural network the basic unit computes the weighted sum of its inputs and then forwards it through a nonlinear function to other units, the basic unit of the TDNN network is modified by introducing n delays to the input, so a input layer composed of y inputs would generate z = y * (n+1) inputs to the network, corresponding to the past inputs. By employing delays, the neural network can relate and compare the current input to previously observed data. In this way it effectively implements a shortterm memory mechanism. The output values are compared to the expected ones and the error value is obtained and back-propagated through the network, updating the weights and decreasing the prediction error. This procedure is repeated until the results converge to the expected outputs. Among the extensions of the time-delay family of networks is the ATNN network, which extends the TDNN by including the ability to adjust the delays dynamically, therefore allowing a better adaptation to different access patterns, as demonstrated by Day and Davenport (1993). A statistical approach for prediction is introduced by Bayesian networks (Morawski, 1989), that
344
On Application Behavior Extraction and Prediction
consider the correlation and conditional dependences among different patterns in order to predict future accesses. A different prediction strategy relies on Markov Chains (Bolch, Greiner, Meer & Trivedi, 1998), representing a sequence of application state changes, with given probability for each transition. Thus, the complete application execution can be represented as a sequence of state changes. By knowing the probability of each such change, it is possible to predict future application behavior (Dodonov et al, 2006). This approach is further extended by Hidden Markov Chains Model (HMM), which considers series of state changes to realize more complex predictions (Madhyastha & Reed, 1997), and Kalman filter, which aims at forecasting the behavioral trends (Kohler, 1997). It is also possible to employ similarity and clustering techniques, such as the ones used by the SOM neural network, to forecast future application behavior. Among such techniques are Temporal Kohonen Maps, or TKM (Chappel & Taylor, 1993), which aims at classifying the application behavior according to its temporary states. This technique introduces the concept of short-term memory, which is used to store the historical neighborhood changes for each application state. A different strategy is used by auto-regressive SOM (AR-SOM) model (Lampinen & Oja, 1989), which represents each application state as an auto-regressive vector, composed of a time series of past application behaviors. Therefore, such approach allows to use the traditional SOM model to predict possible application behavior changes. Another approach, also based on SOM network, is represented by the Vector-Quantized Temporal Associative Memory (VQTAM) network, proposed by Barreto and Araujo (2004). This method combines the application behavior classification with an associative memory to predict future application events. The short-term memory concept for data classification and prediction is employed by recurrent neural networks, characterized by usage of connections to store recent events, such as the Elman network (Kremer, 1995), which employs a special context layer to maintain historical events, or Hopfield network (Hopfield, 1988) that acts as an associative memory between input and output patterns. Such networks provide a fast access to recent events, and are highly efficient for short-time predictions. However, while such approaches can be effective for short-term prediction, they do not provide adequate results for longterm sequences, requiring a different approach. Therefore, Long-Short Term Memory (LSTM) network was introduced in researches by Hochreiter, Schmidhuber and Gers (Hochreiter & Schmidhuber, 1997; Gers & Schmidhuber, 2000), combining conventional short-term memory with a long-term prediction, noise detection and reduction techniques. The network aims at maintaining a constant error rate flow, preventing false positives and resulting in a superior prediction precision when compared to other approaches, as shown in several works (Pérez-Ortiz, Gers & Schmidhuber, 2003). The long-term prediction is differentiated from short-term by introducing memory gates which control whether the memory content should be modified. This approach results in an effective prediction for both short and long-range sequences, even over noisy observations. It also requires a lower computational cost. However, the network topology must be carefully planned for an efficient prediction. A novel approach for behavior prediction was simultaneously introduced by several authors, represented by techniques such as Echo State Networks, Liquid State Machines and Backpropagation-Decorrelation, all known under the name of Reservoir Computing (Jaeger, 2007). Their functionalities are similar to recurrent networks, storing temporal information in internal network nodes. The proposed approaches aim at providing efficient and low-cost prediction of series with a priori unknown behavior, being based on a large network with randomly generated units, known as reservoir. The input signal is submitted to
345
On Application Behavior Extraction and Prediction
the network, being mapped into a higher dimension by the reservoir dynamics. A supervising mechanism, controlled by the output weight vector, is trained to read the state of the reservoir and map it according to the desired output. Such mapping is known as the echo property of the reservoir. As only the output weights of the network are modified, it results in a constant execution time. The results obtained from such techniques are promising, as they are able to outperform previously employed techniques by several orders of magnitude according to Jaeger (2007). Among the limitations of reservoir computing are the learning instability, inflicted by unconstrained training, and the size of reservoir network, which is often composed of thousands of neurons. Aiming at overcoming such limitation, a new approach was introduced recently by Gao et al. (2007), known as Spiral Recurrent Neural Network (SRNN). The proposed network introduces fading memory feature by combining a trainable hidden recurrent layer with the echo property of reservoir computing, resulting in highly effective prediction for both short-term and long-term periods according to the researchers.
APPLICATIONS The usage of process behavior classification and prediction aiming performance improvements in distributed systems has received considerable attention over the last decades, and currently is used in different areas of high-performance computing. Devarakonda and Iyer (1989) use the k-means technique to evaluate the application history, determining the critical execution points and overall resource utilization at different execution states. Linear classification, as performed by SVM, can be used for pattern prediction over long disordered sequences, as demonstrated by Hirose et al. (2007), and for time series prediction, as shown by Muller et al. (1997) and Chen et al. (2004). Markov chains and time-delay neural network are employed for access pattern detection and prediction in distributed systems by Sakr et al. (1996) and Dodonov and Mello (2006, 2007). The works demonstrated the efficiency of such techniques for correct access pattern representation in distributed systems, aiming at support the data prefetching and load balancing. Artificial intelligence techniques are used for distributed scheduling in the MidHPC project (Mello et al., 2007), intended for transparent execution of concurrent application over large distributed environment. Application behavior knowledge is employed by the Route scheduling algorithm (Mello, Senger, & Yang, 2006), which deploys jobs based on the observed behavior. The Route algorithm is further extended by by the RouteGA algorithm, (Mello, Andrade, Senger, & Yang, 2007), which takes scheduling decisions considering the network analysis performed by a genetic algorithm, and migrates processes according to the network environment configuration (Dodonov, Mello, & Yang, 2005). The nature of data accesses in distributed systems is studied by Kroeger and Long (1999), demonstrating that the analysis of execution history can improve the prediction results in up to 80%. Similar results were obtained in research by Byna et al. (2004), evaluating MPI accesses in distributed applications. The prediction of process behavior is also used by Martin et al. (2003) to improve the trade-off between latency and bandwidth in shared memory multiprocessors. Neural networks-based approaches are also used for job scheduling in grid environment by Ishii, Mello and Yang (2007), as well as for user behavior extraction and classification (Santos, Mello, & Yang, 2007).
346
On Application Behavior Extraction and Prediction
Finally, a series of innovative process scheduling approaches based on application behavior analysis are studied in researches by Mello and Yang (2008), evaluating chaos theory approaches; and Nery et al. (2006), distributing processes over the network considering Ant colony optimization.
CONCLUSION In this chapter, we presented different techniques for application behavior extraction, classification and prediction, ranging from source code evaluation approaches and process execution tracing to platformspecific techniques, such as MPI-based approaches and distributed application execution monitoring. The correct identification and classification of different process execution states are responsible for the effectiveness of behavior prediction. Therefore, several statistical and artificial intelligence-based approaches were studied for access pattern extraction, classification and prediction. Finally, applications based on different behavior prediction strategies were discussed in this chapter to illustrate the effectiveness of such techniques.
REFERENCES Albertini, M. K., & Mello, R. F. (2007). A self-organizing neural network for detecting novelties. In Sac ’07: Proceedings of the 2007 ACM Symposium on Applied Computing (pp. 462–466). New York: ACM Press. Andrade Filho, J. A., Mello, R. F., Dodonov, E., Senger, L. J., Yang, L. T., & Li, K. C. (2008). Toward an Efficient Middleware for Multithreaded Applications in Computational Grid. In IEEE International Conference on Computational Science and Engineering, (p. 147-154). Arpaci-Dusseau, A. C., Culler, D. E., & Mainwaring, M. (1998). Scheduling with Implicit Information in Distributed Systems. In Proceedings of ACM SIGMETRICS’98 (pp. 233–248). Barreto, G. A., & Araujo, A. F. R. (2004). Identification and control of dynamical systems using the self-organizing map. In Special Issue of IEEE Transactions on Temporal Coding (pp. 1244-1259). Berthold, M. (1994). A time delay radial basis function network for phoneme recognition. IEEE World Congress on Computational Intelligence., 1994 IEEE International Conference on Neural Networks, 7. Bianchini, R., Pinto, R., & Amorim, C. L. (1998). Data prefetching for software DSMs. In International Conference on Supercomputing (pp. 385-392). Bolch, G., Greiner, S., de Meer, H., & Trivedi, K. S. (1998). Queueing networks and markov chains: modeling and performance evaluation with computer science applications. New York: Wiley-Interscience. Bradley, P. S., Fayyad, U. M., & Reina, C. (1998). Scaling clustering algorithms to large databases. In Knowledge Discovery and Data Mining (pp. 9-15).
347
On Application Behavior Extraction and Prediction
Byna, S., Sun, X.-H., Gropp, W., & Thakur, R. (2004). Predicting memory-access cost based on dataaccess patterns. In Cluster ’04: Proceedings of the 2004 IEEE International Conference on Cluster Computing (pp. 327–336). Washington, DC: IEEE Computer Society. Carpenter, G. A., & Grossberg, S. (1987). Art 2: Self-organization of stable category recognition codes for analog input patterns. Applied Optics, 26, 4919–4930. doi:10.1364/AO.26.004919 Chan, A., Gropp, W., & Lusk, E. (2003). User’s guide for mpe extensions for mpi programs. Technical Report ANL-98/xx, Argonne National Laboratory, 1998. Retrieved from ftp://ftp.mcs.anl.gov/pub/mpi/ mpeman.ps. Chappell, G. J., & Taylor, J. G. (1993). The temporal kohonen map. Neural Networks Journal, 6(3), 441–445. doi:10.1016/0893-6080(93)90011-K Chen, B. J., Chang, M. W., & Lin, C. J. (2004). Load forecasting using support vector machines: A study on eunite competition 2001. IEEE Transactions on Power Systems, 19(4), 1821–1830. doi:10.1109/ TPWRS.2004.835679 Corbalan, J., Martorell, X., & Labarta, J. (2001). Improving Gang Scheduling through Job Performance Analysis and Malleability. In International Conference on Supercomputing (pp. 303–311). Sorrento, Italy. Day, S. P., & Davenport, M. R. (1993, March). Continuous-time temporal back-propagation with adaptable time delays. IEEE Transactions on Neural Networks, 4(2), 348–354. doi:10.1109/72.207622 de Mello, R. F., Filho, J. A. A., Senger, L. J., & Yang, L. T. (2007). RouteGA: A grid load balancing algorithm with genetic support. In AINA (pp. 885-892). New York: IEEE Computer Society. de Mello, R. F., Senger, L. J., & Yang, L. T. (2006). Performance evaluation of route: A load balancing algorithm for grid computing. Research Initiative, Treatment Action, 13(1), 87–108. Devarakonda, M. V., & Iyer, R. K. (1989). Predictability of process resource usage: A measurement-based study on UNIX. IEEE Transactions on Software Engineering, 15(12), 1579–1586. doi:10.1109/32.58769 Dodonov, E., Mello, R., & Yang, L. T. (2006). Adaptive technique for automatic communication access pattern discovery applied to data prefetching in distributed applications using neural networks and stochastic models. In Proceedings of the ISPA’06. Dodonov, E., & Mello, R. F. (2007). A model for automatic on-line process behavior extraction, classification and prediction in heterogeneous distributed systems. In CCGRID’07: Proceedings of the Seventh IEEE International Symposium on Cluster Computing and the Grid (pp. 899–904). Washington, DC: IEEE Computer Society. Dodonov, E., Mello, R. F., & Yang, L. T. (2005). A network evaluation for lan, man and wan grid environments. In L. T. Yang, M. Amamiya, Z. Liu, M. Guo, & F. J. Rammig (Eds.), EUC, 3824 (pp.11331146). Berlin: Springer.
348
On Application Behavior Extraction and Prediction
Dodonov, E., Sousa, J. Q., & Guardia, H. C. (2004). Gridbox: securing hosts from malicious and greedy applications. In Proceedings of the 2nd Workshop on Middleware for Grid Computing (pp. 17–22). New York: ACM Press. dos Santos, M. L., de Mello, R. F., & Yang, L. T. (2007). Extraction and classification of user behavior. In T.-W. Kuo, E. H.-M. Sha, M. Guo, L. T. Yang, & Z. Shao (Eds.), EUC (LNCS Vol. 4808, p. 493-506). Berlin: Springer. Fang, W., Wang, C. L., Zhu, W., & Lau, F. C. M. (2004). Pat: a postmortem object access pattern analysis and visualization tool. In CCGRID 2004, 4th IEEE/ACM International Symposium on Cluster Computing and the Grid, (pp. 379-386). Chicago: IEEE Computer Society. Feitelson, D. G., Rudolph, L., Schwiegelshohn, U., Sevcik, K. C., & Wong, P. (1997). Theory and practice in parallel job scheduling. In Job Scheduling Strategies for Parallel Processing (LNCS Vol. 1291, pp. 1–34). Berlin: Springer Verlag. Fischer, P. C. (1965). On formalisms for turing machines. Journal of the ACM, 12(4), 570–580. doi:10.1145/321296.321308 Fritzke, B. (1995). A growing neural gas network learns topologies. In G. Tesauro, D. S. Touretzky, & T. K. Leen (Eds.), Advances in Neural Information Processing Systems 7 (pp. 625–632). Cambridge MA: MIT Press. Gabriel, E., Fagg, E. G., Bosilca, G., Angskun, T., Dongarra, J. J., Squyres, J. M., et al. (2004). Open MPI: Goals, concept, and design of a next generation MPI implementation. In Proceedings of 11th European PVM/MPI Users’ Group Meeting, (pp. 97-104). Gao, H., Sollacher, R., & Kriegel, H. P. (2007). Spiral recurrent neural network for online learning. In Proceedings of 15th European Symposium on Artificial Neural Networks (pp. 483–488). Gers, A. F., & Schmidhuber, J. (2000, 25). Long short-term memory learns context free and context sensitive languages. In Proceedings of IDSIA, 3. Gibbons, R. (1997). A historical application profiler for use by parallel schedulers. In Job Scheduling Strategies for Parallel Processing (pp. 58–77). Berlin: Springer Verlag. Gropp, W., Lusk, E., Doss, N., & Skjellum, A. (1996, September). A high-performance, portable implementation of the MPI message passing interface standard. Parallel Computing, 22(6), 789–828. doi:10.1016/0167-8191(96)00024-5 He, J., Tan, A.-H., & Tan, C.-L. (2004). Modified art 2a growing network capable of generating a fixed number of nodes. IEEE Transactions on Neural Networks, 15(3), 728–737. doi:10.1109/ TNN.2004.826220 Hirose, S., Shimizu, K., Kanai, S., Kuroda, Y., & Noguchi, T. (2007). Poodle-l: A two-level SVM prediction system for reliably predicting long disordered regions. Bioinformatics (Oxford, England), 23(16), 2046–2053. doi:10.1093/bioinformatics/btm302 Hochreiter, S., & Schmidhuber, J. (1997). Long short-term memory. Neural Computation, 9(8), 1735–1780. doi:10.1162/neco.1997.9.8.1735
349
On Application Behavior Extraction and Prediction
Hopfield, J. J. (1988). Neural networks and physical systems with emergent collective computational abilities. Neurocomputing: Foundations of Research, 457–464. Hornik, K., Stinchcombe, M., & White, H. (1989). Multilayer feedforward networks are universal approximators. Neural Networks, 2(5), 359–366. doi:10.1016/0893-6080(89)90020-8 Huband, S., & McDonald, C. (2001). A preliminary topological debugger for MPI programs. In Proceedings of the First IEEE/ACM International Symposium on Cluster Computing and the Grid, (pp. 422-429). Ishii, R. P., de Mello, R. F., & Yang, L. T. (2007). A complex network-based approach for job scheduling in grid environments. In R. H. Perrott, B. M. Chapman, J. Subhlok, R. F. de Mello, & L. T. Yang (Eds.), HPCC (LNCS Vol. 4782, p. 204-215). Berlin: Springer. Ishikawa, Y., Matsuda, M., Kudoh, T., Tezuka, H., & Sekiguchi, S. (2003). The design of a latency-aware mpi communication library. In Swopp03. Jaeger, H. (2007). Echo state network. Scholarpedia, 2(9), 2330. Available at http://www.scholarpedia. org/article/Echo_state_network Jain, R. (1991). The art of computer systems performance analysis: Techniques for experimental design, measurement, simulation, and modeling. New York: John Wiley and Sons. Jiang, D., Tang, C., & Zhang, A. (2004). Cluster analysis for gene expression data: A survey. IEEE Transactions on Knowledge and Data Engineering, 16(11), 1370–1386. doi:10.1109/TKDE.2004.68 Kalman, R. E. (1960). A new approach to linear filtering and prediction problems. Transactions of the ASME–Journal of Basic Engineering, 82(Series D), 35–45. Kaski, S., & Oja, E. (1999). Kohonen maps. New YorkUSA: Elsevier Science Inc. Keskar, D., & Leibowitz, M. (2005). Speeding up openoffice: profiling, tools, approaches. In First Openoffice.org Conference. Kotz, D., & Ellis, C. S. (1993). Practical prefetching techniques for multiprocessor file systems. Journal of Distributed and Parallel Databases, 1(1), 33–51. doi:10.1007/BF01277519 Kremer, S. C. (1995). On the computational power of Elman-style recurrent networks. IEEE Transactions on Neural Networks, 6(4), 1000–1004. doi:10.1109/72.392262 Kroeger, T. M., & Long, D. D. E. (1999). The case for efficient file access pattern modeling. In Workshop on Hot Topics in Operating Systems (p. 14-19). Kunze, M., & Steffens, J. (1995). Growing cell structure and neural gas; incremental neural networks. In Proceedings of the 4th AIHEP Workshop, Pisa, Italy. Lampinen, J., & Oja, E. (1989). Self-organizing maps for spatial and temporal AR models. In M. Pietikainen & J. Roning (Eds.), Proceedings of 6th SCIA, Scandinavian Conference on Image Analysis (pp.120–127). Helsinki, Finland: Suomen Hahmontunnistustutkimuksen seura r. y.
350
On Application Behavior Extraction and Prediction
Lei, H., & Duchamp, D. (1997). An analytical approach to file prefetching. In 1997 USENIX Annual Technical Conference. Anaheim, USA. Liao, T. W., Celmins, A. K., Robert, J., & Hammell, I. (2003). A fuzzy c-means variant for the generation of fuzzy term sets. Fuzzy Sets and Systems, 135(2), 241–257. doi:10.1016/S0165-0114(02)00136-7 Loiseaux, C., Graf, S., Sifakis, J., Bouajjani, A., & Bensalem, S. (1995). Property preserving abstractions for the verification of concurrent systems. Formal Methods in System Design, 6(1), 11–44. doi:10.1007/ BF01384313 Madhyastha, T. M., & Reed, D. A. (1997). Input/output access pattern classification using hidden Markov models. In Proceedings of the Fifth Workshop on Input/Output in Parallel and Distributed Systems (pp. 57–67). San Jose, CA: ACM Press. Marinai, S., Gori, M., & Soda, G. (2005). Artificial neural networks for document analysis and recognition. IEEE Transactions on Pattern Analysis and Machine Intelligence, 27(1), 23–35. doi:10.1109/ TPAMI.2005.4 Marsland, S., Shapiro, J., & Nehmzow, U. (2002). A self-organizing network that grows when required. Neural Networks, 15(8-9), 1041–1058. doi:10.1016/S0893-6080(02)00078-3 Martin, M., Harper, P., Sorin, D., Hill, M., & Wood, D. (2003, June). Using destination-set prediction to improve the latency /bandwidth tradeoff in shared memory multiprocessors. In Proceedings of the 30th Annual International Symposium on Computer Architecture. Mehrotra, S., & Harrison, L. (1996). Examination of a memory access classification scheme for pointerintensive and numeric programs. In ICS’96 (pp. 133-140). Mello, R. F., Andrade, J. A., Dodonov, E., Ishii, R. P., & Yang, L. T. (2007). Optimizing distributed data access in grid environments by using artificial intelligence techniques. In I. Stojmenovic, R. K. Thulasiram, L. T. Yang, W. Jia, M. Guo, & R. F. de Mello (Eds.), ISPA’07 (LNCS Vol. 4742, pp. 125136). Berlin: Springer. Mello, R. F., & Senger, L. J. (2004). A new migration model based on the evaluation of processes load and lifetime on heterogeneous computing environments. In 16th Symposium on Computer Architecture and High Performance Computing (SBAC’2004) Foz do Iguacu, PR, Brazil, (pp. 222–227). Mello, R. F., Senger, L. J., & Yang, L. T. (2005). Automatic text classification using an artificial neural network. High Performance Computational Science and Engineering, 1, 1–21. Mello, R. F., & Yang, L. T. (2008). Prediction of Dynamical, Non-Linear and Unstable Process Behavior. Journal of Supercomputing. Dordrecht, the Netherlands: Springer Netherlands. Morawski, P. (1989). Understanding bayesian belief networks. AI Expert, 4(5), 44–48. Muller, K., Smola, A., Ratsch, G., Scholkopf, B., Kohlmorgen, J., & Vapnik, V. (1997). Predicting time series with support vector machines. Proceedings of the International Conference on Artificial Neural Networks, (pp. 999–1004).
351
On Application Behavior Extraction and Prediction
Nagel, W. E., Arnold, A., Weber, M., Hoppe, H. C., & Solchenbach, K. (1996). VAMPIR: Visualization and analysis of MPI resources. Supercomputer, 12(1), 69–80. Nery, B. R., de Mello, R. F., & Carvalho, A. C. P. Leon Ferreira, & Yang, L. T. (2006). Process scheduling using ant colony optimization techniques. In M. Guo, L. T. Yang, B. D. Martino, H. P. Zima, J. Dongarra, & F. Tang (Eds.), ISPA (LNCS Vol. 4330, p. 304-316). Berlin: Springer. Nethercote, N., & Fitzhardinge, J. (2004, January). Bounds-checking entire programs without recompiling. In Informal Proceedings of the Second Workshop on Semantics, Program Analysis, and Computing Environments for Memory Management (SPACE 2004), Venice, Italy. Pérez-Ortiz, J. A., & Gers, F. A. E., D., & Schmidhuber, J. (2003). Kalman filters improve LSTM e network performance in problems unsolvable by traditional recurrent nets. In Neural Networks, 16(2). Powell, M. (1987). Radial basis functions for multivariable interpolation: a review. Clarendon Press Institute Of Mathematics And Its Applications Conference Series, (pp. 143–167). Rosca, J. P., Erdogmus, D., Principe, J. C., & Haykin, S. (Eds.). (2006). Independent component analysis and blind signal separation, in Proceedings of 6th International Conference, ICA 2006, Charleston, SC. New York: Springer. Sakr, M., Giles, C., Levitan, S., Horne, B., Maggini, M., & Chiarulli, D. (1996). On-line prediction of multiprocessor memory access patterns. In Proceedings of the IEEE International Conference on Neural Networks (pp. 1564-1569). Schölkopf, B., & Smola, A. J. (2001). Learning with kernels: Support vector machines, regularization, optimization, and beyond (adaptive computation and machine learning). Cambridge, MA: The MIT Press. Schuster, A. (2003). Scalable distributed model checking: Experiences, lessons, and expectations. Electronic Notes on Theory of Computer Science, 89(1). Senger, L. J., Mello, R. F., Santana, M. J., & Santana, R. C. (2005). An on-line approach for classifying and extracting application behavior on Linux. In L. T. Yang & M. Guo (Eds.), High Performance Computing: Paradigm and Infrastructure (chap. 20). New York: John Wiley and Sons. Silva, F. A. B. D., & Scherson, I. D. (2000). Improving parallel job scheduling using runtime measurements. In D. G. Feitelson & L. Rudolph (Eds.), Job Scheduling Strategies for Parallel Processing (LNCS, Vol. 1911, pp. 18–38). Berlin: Springer Verlag. Smith, W., Foster, I. T., & Taylor, V. E. (1998). Predicting application run times using historical information. In JSSPP (p. 122-142). Squyres, J. M., & Lumsdaine, A. (2003). A Component Architecture for LAM/MPI. In Proceedings of 10th European PVM/MPI Users’ Group Meeting (pp. 379–387). Venice, Italy: Springer-Verlag. Suykens, J. A., & Vandewalle, J. (2000). The K. U. Leuven competition data: a challenge for advanced neural network techniques. In Esann (pp. 299-304)
352
On Application Behavior Extraction and Prediction
Thacker, N. A., Abraham, I., & Courtney, P. (1997). Supervised learning extensions to the clam network. Neural Networks, 10(2), 315–326. doi:10.1016/S0893-6080(96)00074-3 Waibel, A., Hanazawa, T., Hinton, G., Shikano, K., & Lang, K. (1989). Phoneme recognition using time delay neural networks. IEEE Transactions on Acoustics, Speech, and Signal Processing, 37, 328–339. doi:10.1109/29.21701 Weigend, A. S., & Gershenfeld, N. A. (1994). Time series prediction: Forecasting the future and understanding the past. In A. S. Weigend & N. A. Gershenfeld (Eds.), Santa Fe Institute Studies on the Sciences of Complexity, Proceedings of the NATO Advanced Research Workshop on Comparative Time Series Analysis, Santa Fe, New Mexico, May 14-17, 1992. New York: Addison-Wesley Wilding, M., & Behman, D. (2005). Self-service Linux: mastering the art of problem determination (1st edition). Upper Saddle River, NJ: Prentice Hall. Zemouri, R., Racoceanu, D., & Zerhouni, N. (2003). Recurrent radial basis function network for timeseries prediction. Engineering Applications of Artificial Intelligence, 16(5-6), 453–463. doi:10.1016/ S0952-1976(03)00063-0
KEY TERMS AND DEFINITIONS Application Behavior Extraction: The process of extraction and transcription of events observed during the application execution. Application Behavior Classification: Evaluation of extracted application behavior, aiming at determining the most representative execution patterns and reducing the data dimensionality. Application Behavior Prediction: Forecasting of future application actions with base on previously observed behavior. Application Knowledge: The transcription of resource usage by applications during the course of execution. Data Prefetching: Anticipated reading of data elements according to the forecasted execution patterns, aiming at reducing the access latency. Process Execution States: Set of information which defines the process behavior on a given time instant. Process Scheduling: Allocation of applications across the environment, aiming at reducing the system idleness and minimizing the total execution time.
353
354
Chapter 16
A Structured Tabu Search Approach for Scheduling in Parallel Computing Systems Tore Ferm Sydney University, Australia Albert Y. Zomaya Sydney University, Australia
ABSRACT Task allocation and scheduling are essential for achieving the high performance expected of parallel computing systems. However, there are serious issues pertaining to the efficient utilization of computational resources in such systems that need to be resolved, such as, achieving a balance between system throughput and execution time. Moreover, many scheduling techniques involve massive task graphs with complex precedence relations, processing costs, and inter-task communication costs. In general, there are two main issues that should be highlighted: problem representation and finding an efficient solution in a timely fashion. In the work proposed here, the authors have attempted to overcome the first problem by using a structured model which offers a systematic method for the representation of the scheduling problem. The model used can encode almost all of the parameters involved in a scheduling problem in a very systematic manner. To address the second problem, a Tabu Search algorithm is used to allocate tasks to processors in a reasonable amount of time. The use of Tabu Search has the advantage of obtaining solutions to more general instances of the scheduling problem in reasonable time spans. The efficiency of the proposed framework is demonstrated by using several case studies. A number of evaluation criteria will be used to optimize the schedules. Communication- and computation-intensive task graphs are analyzed, as are a number of different task graph shapes and sizes.
INTRODUCTION The impressive proliferation of the use of parallel processor systems these days in a great variety of applications is the result of many breakthroughs over the last two decades. These breakthroughs span DOI: 10.4018/978-1-60566-661-7.ch016
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
A Structured Tabu Search Approach
a wide range of specialities, such as device technology, computer architectures, theory, and software tools. However, there remain many problems that need to be addressed which will keep the research community busy for years to come (Zomaya, 1996). The scheduling problem involves the allocation of a set of tasks or jobs to resources, such that the optimum performance is obtained. If these tasks are not inter-dependent the problem is known as task allocation. In a parallel computing system one would expect a linear speedup in performance when more processors (or computers) are employed. However, in practice, this is generally not the case, due to such factors as communication overhead, control overhead, and precedence constraints between tasks (Lee et al., 2008). Thus, the development of efficient scheduling techniques would improve the operation of parallel processor systems. The efficiency of a parallel processor system is commonly measured by completion time, speedup, or throughput, which in turn reflect the quality of the scheduler. Many heuristic algorithms have already been developed which provide effective solutions. Most of these methods, however, can solve only limited instances of the scheduling problem (El-Rewini, 1996, Macey and Zomaya, 1997, Nabhan and Zomaya, 1997). The scheduling problem is known to be NP-complete for the general case and even for many restricted instances (Salleh and Zomaya, 1999). For this reason, scheduling is usually handled by heuristic methods which provide reasonable solutions for restricted instances of the problem (El-Rewini, 1996). Most research on scheduling has dealt with the problem when the tasks, inter-processor communication costs, and precedence constraints are fully known. When the task information is known a priori, the problem is known as static scheduling. On the other hand, when there is no a priori knowledge about the tasks the problem is known as dynamic scheduling. For dynamic scheduling problems with precedence constraints optimal scheduling algorithms are not known to exist (Lee and Zomaya, 2008). In non-preemptive scheduling, once a task has begun on a processor, it must run to completion before another task can start execution on the same processor. In preemptive scheduling, it is possible for a task to be interrupted during its execution, and resumed from that position on the same or any other processor, at a later time. Although preemptive scheduling requires additional overhead, due to the increased complexity, it may perform more effectively than non-preemptive methods (El-Rewini, 1996). Furthermore, a non-adaptive scheduler does not change its behaviour in response to feedback from the system. This means that it is unable to adapt to changes in system activity. In contrast, an adaptive scheduler changes its scheduling according to the recent history and/or current behaviour of the system (Zomaya and Teh, 2001, Seredynski and Zomaya, 2002). In this way, adaptive schedulers may be able to adapt to changes in system use and activity. Adaptive schedulers are usually known as dynamic, since they make decisions based on information collected from the system.
TASK SCHEDULING AND PROBLEM FORMULATION An application can be represented by a Directed Acyclic Graph (DAG), G = (V,E), where V is the set of v nodes, and E is the set of e edges. A node ni, in a DAG represents a task, and the corresponding weight wi, representing the computational cost required to complete that task. An edge (i,j), connecting nodes ni and nj (in the direction i –> j), represents a task precedence constraint, in which ni must be completed before nj can begin, with the corresponding weight, cij, representing the communication cost of sending the required data to task j from task i. This communication cost is only required if nodes ni
355
A Structured Tabu Search Approach
and nj are scheduled onto different processors. A node with no incoming edges is known as an entry task, and one without any outgoing edges is known as an exit task. In the case of multiple entry or exit tasks, a pseudo-entry/exit node is created that has zero-cost edges connecting it to all entry/exit nodes. This simplifies the DAG and does not affect the schedule. A task is considered a ready task if all its precedence constraints have been met, i.e. all parent nodes have completed. The goal of scheduling a DAG is to reduce the fitness criteria specified, by mapping the tasks onto processors, properly ordering the tasks on these processors, and by ensuring that all precedence constraints are met. The most common fitness criterion is a simple measure of the length of the schedule (makespan) produced. However, other methods exist, such as: minimizing the amount of communication across the interconnection network; load balancing the computation as equally as possible among all processors; minimizing idle time on the processors; or any combination of these. Some heuristics also aim at the parallel system architecture and attempt to minimize the setup costs of the parallel processors (or computers) (Bruno et al., 1974, Dogan and Özgüner, 2002). There are a number of different broad techniques that have developed for solving the task scheduling problem. List-based techniques are the most common, and are popular because they produce competitive solutions with relatively low time complexity when compared to the other techniques. The two steps that comprise most list-based techniques are task prioritisation and processor selection, where tasks are prioritised based upon a prioritising function and subsequently mapped onto a processor. (This second step is trivial for homogeneous systems, where the processor speed does not matter.) The algorithms maintain a list of all the tasks ordered by their priority. In clustering techniques, initial clusters contain a single task. An iteration of the heuristic improves the clustering by combining some of the clusters, should the resulting combined cluster reduce the finish time. This technique requires an additional step, when compared to list-based techniques, which involves mapping an arbitrary number of clusters onto a bounded number of processors (or further merging the clusters so that the number of clusters matches the number of processors available). Duplication-based techniques are another design which revolves around reducing the amount of communication overhead in a parallel execution. Therefore by (redundantly) duplicating certain tasks, and running them on more than one processor, the precedence constraints are maintained, but the communication from that duplicated task to a child task is eliminated. Finally the most computationally expensive of the scheduling techniques is the guided random search technique. This technique involves some very popular algorithms, such as Simulated Annealing, Genetic Algorithms, Tabu Search and Neural Networks. These algorithms generally require a set of parameters especially tailored to the problem they are attempting to solve. A variety of these different approaches have been compared, and their efficiency compared and Tabu Search performed roughly in the middle of all the approaches on all the tests performed (Siegel and Ali, 2000). In general, the efficient management of both the processors and communication links of a parallel and distributed system is essential in order to obtain high performance (Kwok and Ahmad, 1999). It is unfortunate that the communication links are often the bottleneck in a distributed system, and processors often end up wasting cycles idling while waiting for data from another processor in order to proceed. One different approach is a heuristic that attempts to increase the idle time on a given processor for extended periods of time so that power consumption is reduced for that processing resource (Zomaya and Chan, 2005).
356
A Structured Tabu Search Approach
TABU SEARCH Tabu Search (TS) is best thought of as an intelligent, iterative Hill Descent algorithm, which avoids becoming stuck in local minima by using short- and long-term memory. It has gained a number of key influences from a variety of sources; these include early surrogate constraint methods and cutting plane approaches (Glover and Laguna, 2002). TS incorporates adaptive memory and responsive exploration as prime aspects of the search – in this way it can be considered intelligent problem solving. TS has been proven to be effective when compared to a number of heuristics and algorithms previously proposed (Porto and Ribeiro, 1995), and has been used to solve a wide variety of combinatorial optimisation problems. A very useful introduction to TS can also be found in (Hertz et al., 1995), which demonstrates the main attributes and applications of this powerful search technique.
Short Term Memory Tabu Search’s short term memory focuses on restricting the search space to avoid revisiting solutions and cycling. A list of previously visited solutions is recorded during the search that, along with a value that represents the lifetime that the move is to remain Tabu (or restricted), represents the history of the search. The size of this tabu list can also affect the search considerably. If the size is too small then the primary goal of the short term memory, preventing cycling, might not be achieved. Conversely if it is too large, then too many restrictions are created, which limit the search space covered. Unfortunately, there is no exact method for determining the proper value to prevent cycling in an optimisation problem such as task scheduling. The existence of the tabu list does have the side effect of denying the search from exploring certain areas of the search space in some cases. Unlike Genetic Algorithms or Simulated Annealing, TS attempts to avoid randomization whenever possible, employing it only when other implementation approaches are cumbersome.
Longer Term Memory Long-term memory is generally frequency-based, and keeps track of the number of times a certain attribute has occurred and the value of the solution while it was present. Long-term memory is used in TS in order to apply graduated tabu states, which can be used to define penalty and incentive values to modify the evaluation of moves. This allows certain aspects of a solution to increase (or decrease) the overall fitness of a move. In this way a move that might provide a lower makespan might be chosen because an attribute it contains makes the resulting solution beneficial, or helps lead the search into a promising search space.
Intensification Intensification strategies are based on modifying choice rules in order to guide the search towards solutions that have particular promising attributes, which have been discovered to be historically good. Similarly, they may also change the search space entirely to a promising region, in order to more thoroughly analyze the area.
357
A Structured Tabu Search Approach
Diversification Diversification is performed in TS in order to visit areas of the search space that may remain ignored due to the nature of the search. The easiest way to reach these areas is to perform a number of random restarts from differing points on the search plane. Diversification strategies are employed within TS for a variety of reasons. The chief among these reasons is to avoid cycling or visiting the same set of solutions repeatedly. Other reasons for diversification include adding robustness to the search and escaping from local optima. Genetic Algorithms use randomisation and population based techniques in order to diversify their search domain, while Simulated Annealing also uses randomisation in the form of the temperature function. Diversification is particularly useful when better solutions can only be reached by crossing barriers in the solution space.
Implementation An analysis of previous scheduling heuristics and algorithms has proven that they do not account for the amount of communication present in the schedules produced. Many of the previous designs have either ignored communication altogether, assumed communication is constant, or have used communication, but considered it to have no bearing on the outcome of the final schedule. The TS implementation has been developed with a variety of schedule evaluation criteria, in order to determine whether the schedules produced are effectively using the computational resources available, while limiting the use of potentially limiting factors such as the interconnection network. Each of these evaluation criteria also aims to minimize the makespan (or increase speedup) of the schedules produced, in order for TS to remain competitive (Porto and Ribeiro, 1995).
Design Overview As mentioned previously, TS has been proven to be an effective scheduling technique, thus it provides a good basis to develop a scheduler for heterogeneous parallel systems. This TS implementation consists of a number of classes, each providing a necessary role in the TS; it has been very loosely based off a TS skeleton that has been previously developed (Blesa et al., 2001): •
Solution: Represents a solution to the task scheduling problem. Contains the current schedule and fitness rating, also providing methods to alter the solution legally (i.e. performing moves). Movement: Represents a move from one solution to a neighbouring one. This can either be moving a task from one processor to another, or swapping the processor assignments of two tasks. Solver: Runs the actual TS and provides the means to keep track of the current solution and the best solutions. TabuStorage: Is a list of all the moves that have taken place, moves currently considered tabu have a TabuLife greater than 0 iterations.
•
• •
There are also two auxiliary classes:
358
A Structured Tabu Search Approach
• •
Problem: Represents the Task Graph itself. Contains all the precedence constraints, task computation values (per processor), and inter-task communication values. Setup: A simple class containing a number of variables that can be provided to the TS in order to customise it further, including the Aspiration Plus parameters, TabuLife, etc.
The general diversification steps that exist within most TS implementations, in order to increase the variety of the solutions explored, have been altered to include a system that automatically increases the Figure 1. A description of the Tabu Search algorithm
359
A Structured Tabu Search Approach
Figure 2. The algorithm for generating an initial solution
number of processors available on-the-fly. As the solution becomes stagnant at a particular number of processors, another processor is added and the algorithm begins again from this new point. In this way, the search need only be run once, with a maximum number of processors specified – the search will proceed until it reaches a maximum set number of iterations, or reaches the processor limit. It can be shown that the optimum number of processors may not always be the largest provided – depending on the structure of the task graph itself. The generalized graphical structure of the TS implementation algorithm is shown in Figure 1 with a brief algorithm description in pseudo code.
Initialization The random task graphs for this thesis have been generated using Task Graphs For Free (TGFF) version 3.0 (Dick et al., 1998). There are three important aspects contained within the ‘.tgff’ file; the properties of the task graph itself, the processors (computation), and the network (communication). The task graph properties are a listing of the nodes and edges of the task graph, also containing their type. The edges also represent the precedence constraints within a DAG, there is a single list containing the edge type to communication costs relationship, as it is assumed that the network is constant throughout the parallel system. The processor properties contain a list of types, with corresponding computational cost (these map to the task types provided in the task graph properties section of the file) – there is a separate list for each processor. In the initialisation phase, before the TS begins, the properties of the task graph are read into a number of data structures, which are used to represent the tasks themselves, the precedence constraints, and the computational costs for each processor. The initial solutions for the current_solution and best_solution are generated here using a greedy algorithm, so as to provide a starting point for the algorithm.
Initial Solution The initial solution generated by the TS implementation is a greedy heuristic algorithm, ensuring each task’s earliest finish time (EFT). The finish time is used instead of the start time on a heterogeneous processing system, because the computational cost is not fixed. At each iteration, a task is selected and assigned to the processor that will provide it with the EFT. This algorithm maintains precedence constraints and benefits from the heterogeneity by allowing it
360
A Structured Tabu Search Approach
to make a decision based upon both the communication time (if the processor is different to a parent node) and the computation cost of each particular processor (Figure 2).
Neighborhood A neighborhood of solutions is obtained by removing a single task from the task list of one processor and moving it to the task list of another. The entire neighbourhood is obtained by going through every task, and moving it to every other processor in the system. To expand upon the neighbourhood and to help expand the search area, we have added another move category – the swap move. In this move, two tasks are selected and their processor assignments are swapped. In this way the search can proceed further within fewer moves (if the move is worth making), at the expense of some computational efficiency – since more moves are present in each neighbourhood, more should be examined at each iteration of the search. It also allows the search to escape a poor area of the solution space, by allowing the search to ‘look-ahead’ two moves, as opposed to a single step. Thus a neighbouring solution is a solution that differs by a single task assignment, or the swapping of two task assignments. Each move consists of relabelling the processor a task belongs to. A move consists of a source and destination processor, and either one or two task ids. A solution’s neighbourhood is generated every iteration of the search in the form of a move list, which is the list of moves possible from the current solution to transform it into all possible neighbouring solutions. These moves do not include moves considered Tabu, which are located in the tabu list.
Candidate List We have used the Aspiration Plus candidate selection criteria in order to reduce the computational cost of the TS implementation. In Aspiration Plus, moves are analyzed until a move under the given threshold is found, called first. The search continues for plus moves, whereupon the best move found is made (Rangaswamy, 1998). This strategy is further strengthened by the use of a min and max value, the search will always analyze min moves, but never more than max. The user specifies three variables (within the Setup class) for the Aspiration Plus candidate selection: • • •
max – the maximum number of moves to analyze, min – the minimum number of moves to analyze, and plus – the amount of moves to search after first is found.
Unfortunately, while the Aspiration Plus candidate selection criteria dramatically reduces the computational cost of the TS by several orders of magnitude, there remains the possibility that good moves are not evaluated in a given iteration, because only a small subset of moves is considered.
Tabu List The main mechanism for using memory within TS is the tabu list, a list of all the moves that have been made so far, along with a time limit specifying the number of iterations that they are to remain tabu. Each move made within the search is stored inversely within the tabu list, with its associated tabulife.
361
A Structured Tabu Search Approach
Table 1. Evaluation criteria Function
Description
Minimize Length (makespan)
The goal of most scheduling research, to reduce the overall length of the solution schedule.
Minimize Communication
Minimizes the total amount of communication present in the final solution as well as minimize the length of the schedule. A good compromise between finding a good schedule, and an efficient use of network resources.
Load Balance
Spreads the load of computation as evenly as possible among the available processors, while still attempting to keep the overall length of the schedule to a minimum.
Combination
This function attempts to minimize communication, balance the load as much as possible among the component processors, and minimize the length of the final solution.
This short-term memory function is used to prevent the search from cycling or returning to previously visited solutions easily. The tabu list must be checked before a move is to be applied, in order to ensure that a tabu move is not made. Merely being located within the tabu list is not enough; the move must also have a tabulife value greater than zero to be considered tabu. If a move located within the tabu list has a tabulife value of zero, it means that the inverse move had been made previously, has since become non-tabu, and thus is available to be performed again.
Evaluation Functions Specified by the user, a number of different evaluation functions of the solutions can be invoked. These evaluation functions allow the user to determine the governing factors they want to be used in evaluating the fitness of a solution found by the algorithm. While the overall goal of many scheduling algorithms has been to reduce the overall makespan (or length) of the schedules produced, it is noted that this may not always be the only factor necessary for an efficient solution. The amount of communication present in a solution can determine the load that will be placed upon the interconnection network during the execution of the parallelised application. On a limited bandwidth interconnection network, the cost of placing high loads upon the network is at a premium; therefore it is wise to reduce the overall inter-task communication as much as possible. Modern media and information has increased the amount of bandwidth traversing networks, and this means that the network is becoming more and more important to many different applications. In order to produce competitive solutions in a congested network environment, the amount of communication must be limited. Minimizing the communication used is especially important in communication-intensive applications, where each inter-task communication is likely to be highly expensive. Some parallel systems seek to distribute as much of the computation as evenly as possible over their component processors, in other words: load balancing. This is another measure by which the user can analyze the schedules produced by the TS implementation. This evaluation scheme is useful because the solutions generated have processing time proportional to the speed at which they execute tasks. A processor twice as fast as another, will have two times the amount of tasks scheduled to it, but will maintain the same processing time. Load balancing is also important in time-shared systems, where a user may only have a specific amount of time on each processor in order to execute their parallelized application.
362
A Structured Tabu Search Approach
Figure 3. (a) Task graph generated by TGFF v3.0, 50 tasks, even in/out degree; and (b) Scheduling of task graph in (a) with the TS implementation – using the ‘minimize length’ evaluation criteria
Figure 4. Execution trace of the task graph in Figure 3(a)
363
A Structured Tabu Search Approach
Similarly, a combination of all these methods might be appropriate, the user may want to analyze the schedules for an evenly distributed system that reduces the total amount of communication, with the fastest finish time possible. In all the above cases, the requirements for different systems are catered for by the specific use of differing evaluation functions. Each evaluation function allows the user more control over the properties that the schedules produced contain. Table 1 lists the four evaluation criteria that have been used to determine the effect of communication on the schedules produced by the TS implementation.
Execution Trace The major components of the TS implementation have been described in detail in the previous six sections. Figure 3(a) illustrates what a task graph looks like before it is inputted into the TS implementation. For this brief trace, the ‘minimize length’ evaluation criteria will be used. The search begins with a sequential execution (on a single processor). At each iteration, the search attempts to improve upon the makespan of the schedule by moving a task from one processor to another, or swapping two tasks processor assignments. If the schedule cannot be improved upon in 100 moves, then another processor is added and the algorithm continues. In this case the best solution found for minimizing the makespan of the schedule, was with 15 processors. The resulting schedule can be seen in Figure 3(b), and the general ‘slow-start’ of the parallelization can easily be seen with the top-end of the schedule being very under-utilized when compared to the lower-end. Figure 4 contains a trace of the TS implementation, and the value of the schedule length at each iteration. The trace begins with a sequential schedule on a single processor, and has a value of 460, when the second processor is added the schedule immediately improves to around 200 time units. Similarly when the third processor is added the schedule length drops dramatically again. Each additional processor after this, however only decreases the schedule length minimally. The light line represents the theoretical minimum, which is defined as:
Theoretical Minimum = Sequential Execution Time / Number of Processors The best performance obtained close to the theoretical minimum is at four processors. After this value, the improvement in schedule length fails to keep up with the theoretical minimum – this results in a poorer utilization of the parallel heterogeneous system. The reason the schedule length is able to perform better than the theoretical minimum, and critical path is because of the heterogeneity of the parallel system; where some processors will perform faster than the average (which is used to calculate these values).
RESULTS: COMPUTATION-INTENSIVE CASES A comparative analysis of the different evaluation functions of the schedules proposed are presented in this chapter. More specifically, the results presented in this section will focus on computation-intensive
364
A Structured Tabu Search Approach
Table 2. Task graph degree shapes High In/Low Out Degree
very tall, thin task graphs, less scope for parallelising
Even In/Out Degree
generally in-between the two extremes
Low In/High Out Degree
very wide task graphs, excellent for parallelising
task graphs. Examples of computation-intensive applications include large-scale simulations, such as, the SETI@home class of applications (Anderson et al., 2000), without the need for much communication. Three measures have been used to analyze the quality of the schedules produced and evaluated by the TS implementation. The first is the speedup, which is an important factor when gauging any scheduling algorithm and has been used to analyze the effectiveness of each of the evaluation functions, and this is defined to be: Figure 5. (a) A high in/low out degree task graph, (b) An even in/out degree task graph, and (c) A low in/high out degree task graph
365
A Structured Tabu Search Approach
Table 3. The tests performed for the computation intensive task graphs Degree Even In/Out Degree (5:5)
# of Processors 20
Evaluation Criteria Minimize Communication Minimize Length Load Balance Combination
50
100
150
200
Low In/High Out Degree (3:7)
…
…
High In/Low Out Degree (6:2)
…
…
Speedup = Sequential Execution Time / Parallel Execution Time The sequential execution time is the schedule length of a task graph on a single processor. The parallel execution time is the schedule length of a task graph on multiple processors. The second measure that is used to evaluate the efficiency of a given schedule is the speedup per processor. The speedup per processor can be used to determine the amount of idle time present in the schedule, and can also be referred to as the average utilization of each processor in the parallel system. As the value reaches 1, the processors are reaching full utilization. The upper bound for the speedup per processor is 1.0, and it is defined as:
Speedup per Processor = Speedup / Number of Processors The final factor used to judge the effectiveness of the solutions presented is the communication usage, and is defined to be the amount of communication time units used in a solution divided by the
366
A Structured Tabu Search Approach
Figure 6. Speedup for computation-intensive: (a) high in/low out; (b) Even in/out; and (c) Low in/high out degree task graph sets
sequential execution time.
CCR` = Communication / Sequential Execution Time To test the TS implementation for computationally intensive task graphs, three sets of randomly generated task graphs have been used. The first set contains task graphs with an even in-out degree, the second set contains task graphs with high in degree and low out degree, and the third a low in degree and high out degree. Table 2 describes the various attributes that apply to each shape of task graph, and Figure 5 illustrates these features graphically.
Test Parameters The three test sets each contained five task graphs generated by TGFF v3.0 (Dick et al., 1998). The number of tasks varied in each task graph of a set, ranging from 20 up to 200 tasks, totalling five task graphs per set. The number of tasks was not increased beyond 200 because of the high time complexity of the TS implementation. Such tests would take an unacceptable amount of time to complete. Each of these task graphs was then run four times with the program for 3000 iterations, using all four evaluation
367
A Structured Tabu Search Approach
Figure 7. Speedup per processor for computation-intensive: (a) High in/low out; (b) Even in/out; and (c) Low in/high out degree task graph sets
criteria, which results in a total of over 60 tests being performed. Since these task graphs were computation-intensive, the computation to communication ratio (CCR) was set to 5:1 – this allows for a wider disparity between the computation- and communication-intensive task graphs. Table 3 summarizes the tests performed.
Performance Results The test results are presented in four different sections. The first section is shown in Figure 6, where comparisons between the speedup obtained by the differing evaluation criteria are conducted on a range of differing graph sizes and shapes. The second section consists of an analysis of the number of processors used in the best solution found in each test and the overall usage of these processors, as shown in Figure 7. Communication usage is presented and discussed in the third section, and is shown in Figure 8. The final section presents only a single example, in order to illustrate that the differences between physical features of the task graphs can affect the final solution considerably. This is represented in Figures 9 and 10.
Comparisons with Differing Evaluation Criteria It is shown in Figure 6 that regardless of the evaluation criteria being used, the speedup obtained from the TS implementation is competitive. Each schedule produced generates a speedup value that increases
368
A Structured Tabu Search Approach
Figure 8. Communication usage for computation-intensive: (a) High in/low out; (b) Even in/out; and (c) Low in/high out degree task graph sets
with task graph size and width. This is important because the trade-off between speedup and specialized properties on the schedules produced is very small, the average penalty to the speedup for minimizing communication is less than 30%. Therefore for heterogeneous parallel systems where the network may be congested (or the bottleneck), schedules can be produced that perform on par with the most efficient schedules produced, while also maintaining the minimum load on the interconnection network. Similarly with time-sharing systems, Figure 9. Schedule length & communication usage for a computation-intensive task graph with 100 tasks, with respect to different task graph shapes/types
369
A Structured Tabu Search Approach
Figure 10. Speedup for a computation-intensive task graph with 100 tasks, with respect to different task graph shapes/types
where each processor may only be available for a certain amount of time, the processing can be spread evenly across all processors while still obtaining a competitive speedup. There are a few anomalies present within the results. The limit of 3000 iterations (or moves) for the search (imposed to restrict the overall running time of the algorithm) forced the larger task graphs (150200 tasks) to terminate before they had reached the allotted maximum of 15 processors. This potentially limited speedup possibly attainable, therefore the speedup obtained for the ‘minimize length’ evaluation criteria is not reflective of general results, where it should obtain the fastest speedup. This is a result of the variable time until a new processor is added to the algorithm; as such, the ‘minimize length’ criteria did not add as many processors to the algorithm as some of the other criteria.
Comparisons with Number of Processors Figure 7 shows the results obtained when using the average speedup in Figure 6, and dividing it by the number of processors used in each solution. This shows the overall effectiveness of the speedup, where the closer a solution gets to having a speedup per processor value of 1.0, the more efficient the schedule is in terms of processor usage. Also noticeable is the task graphs that are more parallelisable are able to obtain a higher speedup per processor as the number of tasks increases. This is due to the fact that the schedules provided for these task graphs are able to utilize additional processors more efficiently than the high in/low out degree task graphs, because the task graphs widen faster. The poor speedup per processor of the ‘minimize length’ criteria occurs because many of the solutions produced for these evaluation criteria are very sparse. The slow-start effect of many of the task graphs also reduces the total speedup possible – as the number of processors increases, the amount of idle time at the beginning of the schedule increases, until the task graph begins to widen sufficiently to take advantage of the additional processors.
Minimizing Communication The test results in Figure 8 demonstrate the efficiency of the evaluation criteria on reducing the burden placed upon the network by the parallelized application. There is a significant drop, in the
370
A Structured Tabu Search Approach
Figure 11. Speedup for communication-intensive: (a) High in/low out; (b) Even in/out; and (c) Low in/ high out degree task graph sets
order of over 50%, in the amount of communication placed on the network when either the ‘Combination’ or ‘Minimize Communication’ evaluation criteria are used. As mentioned previously, the penalty in speedup for using these alternate evaluation criteria is minimal when compared to the reduction in communication. The results are clearly consistent throughout the numerous task graphs, and highlight the efficient use of network resources with these evaluation criteria. The computation-intensive task graphs tend to have a very minimal impact on network load due to the very small values of the communication edges. Therefore computation-intensive task graphs are ideal for parallelizing without evaluating the amount of communication being used in a solution. The reason that the ‘Load Balance’ and ‘Minimize Length’ evaluation criteria perform worse than the ‘Minimize Communication’ and ‘Combination’ evaluation criteria, is because they give no regard to the amount of communication being used. They may produce schedules with a higher speedup value but unnecessarily burden the network with additional communication in order to obtain somewhat minimal gains in speedup.
Comparisons with Various Graph Features It is clear from Figure 9 that the task graphs that widen quickly (Low In/High Out and Even In/Out,) both achieve better schedule lengths. This is because the parallel processors can begin to take immediate advantage of the parallelizability of these task graphs. The communication usage is different among all the different task graph types, and is based upon the number and nature of the precedence constraints
371
A Structured Tabu Search Approach
Figure 12. Speedup per processor for communication-intensive: (a) High in/low out; (b) Even in/out; and (c) Low in/high out degree task graph sets
present in each graph. Not surprisingly the trends continue in favor of the highly parallelizable task graphs for speedup and utilization and are shown in Figure 10. The more parallelizable the task graph, the higher the speedup (as also shown in the lower schedule lengths in Figure 8) and higher the utilization in general. The higher utilization is reached because, on average, the wider task graphs begin to use the additional processors a lot sooner than the taller task graphs. The test results presented in Figures 9 and 10 can easily be replicated among the other equivalent tests, but only a single result is presented here to demonstrate that the shape of a task graph significantly limits the speedup achievable in the final schedules.
Results: Communication-Intensive Cases This section will focus on presenting the results for the second set of tests conducted, aimed at communication-intensive task graphs. These differ quite markedly from computation intensive task graphs, where tasks are able to be shifted to other processors with little-to-no penalty. In communicationintensive task graphs, the cost for changing processors tends to be expensive and often unfeasible. Real world examples of communication-intensive applications include any application that is running on time-shared hardware, where one or more components may have to wait for its share to proceed (thus increasing communication times), such as, Acoustic Beam Forming (Lee and Sullivan, 1993). The same performance measurements used in the previous section (speedup, utilization and CCR`) will again be
372
A Structured Tabu Search Approach
Figure 13. Communication usage for communication-intensive: (a) High in/low out; (b) Even in/out; and (c) Low in/high out degree task graphs
used to compare the various evaluation criteria and schedule outputs.
Test Parameters Table 4 shows the tests that were performed on the computation intensive task graphs, and an identical set of tests were conducted on communication intensive task graphs and TGFF v3.0 was used to generate the task graphs. The task graphs themselves differed slightly from the computation intensive ones because of the random nature of the task graph generation. The computation to communication ratio was set to 1:5, so that the effects of the communication on parallelizing applications can be readily seen when compared to results in the previous section.
Performance Results The performance results for the communication intensive task graphs have been split up into three sections. The first section contains a comparison between the speedup produced for a variety of task graph shapes and number of tasks. The second section analyzes the computational efficiency of the solutions produced by the TS implementation. The final section is most important for communication intensive task graphs and displays the amount of communication present in each schedule produced; it is here that we can truly see the differences in schedules produced by both the computation intensive and com-
373
A Structured Tabu Search Approach
munication intensive task graphs.
Comparisons with Differing Evaluation Criteria Figure 11 clearly demonstrates that it is not feasible to parallelise communication intensive task graphs which are not very wide. A speedup value of 1 indicates that there was no improvement on the sequential solution. Similar to the results in the previous section, the wider the task graph, the higher the speedup obtainable. These wide task graphs halved the makespan of their schedules while minimizing the amount of communication present, on all but the smallest task graphs. The other evaluation criteria (which disregard communication) obtained increasing speedups as the number of tasks increased, irrespective of task graph shape.
Comparisons with Number of Processors The speedup per processor is a measure of how utilized, on average, every processor is in the parallel system. To reach a value of 1 the processor must contain no idle time, and this is only achievable in rare cases with more than one processor. The results of a speedup per processor of value 1 contained in Figure 12 are because those task graphs were found to be unsuitable for parallelization, and the produced schedule contained a single processor. A sequential result on a single processor will always return a utilization value of 1, which means 100% processor usage. When compared to the results in the previous section, the utilization of processors changed rapidly depending on the number of processors in the final solution. The computation intensive task graphs, however, increased the utilization of the processors as the number of tasks increased. This is due to the smaller communication costs which allow child nodes to be located on different processors without delaying the overall schedule. In a communication intensive task graph, there is a significant delay for a child node located on a different processor before the child can begin processing – unfortunately this increases the amount of idle time on the processors, reducing the overall utilization of the parallel system. The theoretical upper bound of 1.0 is overstepped a few times in the results. This occurs because of the heterogeneous nature of the parallel system. The sequential time is calculated from the average of all processors available, and if the tasks are run on processors that use a faster time than the average, then the overall utilisation can appear to be more than 100%. Basically, a higher percent of processing is performed in a lower than average amount of time.
Minimizing Communication Communication-intensive task graphs are truly where the communication needs to be taken into account because any communication across processors will be significantly large. Figure 13 clearly shows that if the evaluation criteria contain the need to minimize communication, then in most cases for a communication intensive application it is not feasible to parallelize (this is shown with a value of 0 communication usage for many of the ‘minimize communication’ and ‘combination’ evaluation results). The Low In/High Out Degree and the larger task Even In/Out Degree task graphs, which are the widest, can be parallelized with reasonable efficiency and reduction in communication usage. It should also be noted that when increasing the speedup several times over (see Figure 11), the communication cost for these schedules is alarmingly high. Again, these schedules are only efficient if
374
A Structured Tabu Search Approach
the interconnection network has a lot of bandwidth. Should the network be shared by other systems or be subject to bandwidth restrictions, burdening the network this much is inefficient. For comparative purposes, the communication usage for the ‘minimize length’ and ‘load balance’ evaluation criteria on 150 tasks, is roughly 3-4 times the processing time units required to sequentially compute. This is clearly inefficient, and demonstrates the need to account for communication usage in a communication-intensive task graph schedule if it is to be viable in realistic networks.
CONCLUSION A major goal when designing a scheduling algorithm is to reduce the makespan in order to reduce the running time of the application. Unfortunately this doesn’t always lead to the best use of resources, whether they are computational resources, networking resources, or time itself. Designing proper evaluation criteria in order to efficiently utilize these resources is essential if larger, distributed heterogeneous systems are to become effective (such as Grids). Despite the excellent quality of the schedules the previous work has produced, and accounting for communication costs, all previously proposed algorithms fail to mention how much they utilize the network as part of the criteria for determining the efficiency of a schedule. In this chapter, a variety of evaluation criteria were presented, which demonstrate, in conjunction with a robust Tabu Search implementation for parallel computing systems, that good quality schedules can be produced that are tailored to the specific requirements of the computing system. The most balanced schedules were produced when all three criteria were used collectively in the ‘combination’ evaluation criteria. This resulted in schedules that limited the load to the network, utilized the available processors evenly and generally had a competitive speedup. The ‘minimize length’ criteria generally produced excellent quality solutions in regards to speedup, but this resulted in an extremely poor use of the interconnection network – especially for the communication-intensive task graphs. Conversely, the ‘minimize communication’ criteria produced schedules of reasonable makespan, but limited the load significantly on the interconnection network. Further extensions of this work consist of the reduction of the number of assumptions placed upon the system and taking into account variability in network conditions. Expanding the Tabu Search implementation to take advantage of some of the more advanced features would increase the robustness of the search.
REFERENCES Anderson, D., et al. (2000). Internet computing for SETI. In G. Lemarchand and K. Meech, (Eds.), The Proceedings of Bioastronomy 99: A New Era in Bioastronomy, ASP Conference Series No. 213, (p. 511). San Francisco: Astronomical Society of the Pacific Blesa, M. J., Hernandez, L., & Xhafa, F. (2001). Parallel skeletons for Tabu search method. In The Proceedings of International Conference on Parallel and Distributed Systems (ICPADS). Bruno, J., Coffman, E. G., & Sethi, R. (1974). Scheduling independent tasks to reduce mean finishing time. Communications of the ACM, 17(7), 382–387. doi:10.1145/361011.361064
375
A Structured Tabu Search Approach
Dick, R. P., Rhodes, D. L., & Wolf, W. (1998). TGFF: Task graphs for free. In The Proceedings of the 6th International Workshop on Hardware/Software Codesign, (pp. 97–101). Dogan, A., & Özgüner, F. (2002). Matching and scheduling algorithms for minimizing execution time and failure probability of applications in heterogeneous computing. IEEE Transactions on Parallel and Distributed Systems, 13(3), 308–323. doi:10.1109/71.993209 El-Rewini, H. (1996). Partitioning and scheduling. In A.Y. Zomaya, (ed.), Parallel and Distributed Computing Handbook, (pp. 239–273). New York: McGraw-Hill. Glover, F., & Laguna, M. (2002). Tabu search. New York: Kluwer Academic Publishers, USA. Hertz, A., Taillard, E., & de Werra, D. (1995). A tutorial on Tabu search. Proceedings of Giornate di Lavoro AIRO, (pp.13–24). Kwok, Y.-K., & Ahmad, I. (1999). Static scheduling algorithms for allocating directed task graphs to multiprocessors. ACM Computing Surveys, 31(4), 406–471. doi:10.1145/344588.344618 Lee, C. E., & Sullivan, D. (1993). Design of a heterogeneous parallel processing system for beam forming. In The Proceedings of the Workshop on Heterogeneous Processing, (pp. 113–118). Lee, Y.-C., Subrata, R., & Zomaya, A. Y. (2008). Efficient exploitation of grids for large–scale parallel applications. In A.S. Becker (Ed.) Concurrent and Parallel Computing: Theory, Implementation and Applications, (pp. 8.165–8.184). Hauppauge, NY: Nova Science Publishers. Lee, Y.-C., & Zomaya, A. Y. (2008). Scheduling in grid environments. In S. Rajasekaran & J. Reif (Eds.) Handbook of Parallel Computing: Models, Algorithms and Applications, pp. 21.1–21.19. Boca Raton, FL: Chapman& Hall/CRC Press. Macey, B. S., & Zomaya, A. Y. (1997). A comparison of list scheduling heuristics for communication intensive task graphs. International Journal of Cybernetics and Systems, 28, 535–546. doi:10.1080/019697297125921 Nabhan, T. M., & Zomaya, A. Y. (1997). A parallel computing engine for a class of time critical processes [Part B]. IEEE Transactions on Systems, Man, and Cybernetics, 27(5), 774–786. doi:10.1109/3477.623231 Porto, S. C. S., & Ribeiro, C. C. (1995). A Tabu search approach to task scheduling on heterogeneous processors under precedence constraints. International Journal of High Speed Computing, 7(1). doi:10.1142/S012905339500004X Rangaswamy, B. (1998). Tabu search candidate list strategies in scheduling. In the Proceedings of the 6th INFORMS Advances in Computational and Stochastic Optimization, Logic Programming and Heuristic Search: Interfaces in Computer Science and Operations Research Conference. Salleh, S., & Zomaya, A. Y. (1999). Scheduling in parallel computing systems: fuzzy and annealing techniques. New York: Kluwer Academic Publishers, USA. Seredynski, F., & Zomaya, A. Y. (2002). Sequential and parallel cellular automata-based scheduling algorithms. IEEE Transactions on Parallel and Distributed Systems, 13(10), 1009–1023. doi:10.1109/ TPDS.2002.1041877
376
A Structured Tabu Search Approach
Siegel, H. J., & Ali, S. (2000). Techniques for mapping tasks to machines in heterogeneous computing systems. Journal of Systems Architecture, 46(8), 627–639. doi:10.1016/S1383-7621(99)00033-8 Zomaya, A. Y. (Ed.). (1996). Parallel and distributed computing handbook. New York: McGraw-Hill. Zomaya, A. Y., & Chan, F. (2005). Efficient clustering for parallel task execution in distributed systems. Journal of Foundations of Computer Science, 16(2), 281–299. doi:10.1142/S0129054105002991 Zomaya, A. Y., & Teh, Y.-W. (2001). Observations on using genetic algorithms for dynamic load-balancing. IEEE Transactions on Parallel and Distributed Systems, 12(9), 899–911. doi:10.1109/71.954620
KEY TERMS AND DEFINTIONS Adaptive Scheduler: This type of schedulers changes its scheduling scheme according to the recent history and/or current behaviour of the system. In this way, adaptive schedulers may be able to adapt to changes in system use and activity. Adaptive schedulers are usually known as dynamic, since they make decisions based on information collected from the system. Non-Adaptive Scheduler: This type of schedulers does not change its behaviour in response to feedback from the system. This means that it is unable to adapt to changes in system activity. Non-Preemptive Scheduling: In this class of scheduling once a task has begun on a processor, it must run to completion before another task can start execution on the same processor. Preemptive Scheduling: In this class of scheduling it is possible for a task to be interrupted during its execution, and resumed from that position on the same or any other processor, at a later time. Although preemptive scheduling requires additional overhead, due to the increased complexity, it may perform more effectively than non-preemptive methods. Scheduling: The allocation of a set of tasks or jobs to resources, such that the optimum performance is obtained. If these tasks are not inter-dependent the problem is known as task allocation. When the task information is known a priori, the problem is known as static scheduling. On the other hand, when there is no a priori knowledge about the tasks the problem is known as dynamic scheduling. Tabu Search: Is an intelligent, iterative Hill Descent algorithm, which avoids local minima by using short- and long-term memory. It has gained a number of key influences from a variety of sources; these include early surrogate constraint methods and cutting plane approaches. Tabu search incorporates adaptive memory and responsive exploration as prime aspects of the search.
377
378
Chapter 17
Communication Issues in Scalable Parallel Computing1 C. E. R. Alves Universidade Sao Judas Tadeu, Brazil E. N. Cáceres Universidade Federal de Mato Grosso do Sul, Brazil F. Dehne Carleton University, Canada S. W. Song Universidade de Sao Paulo, Brazil
ABSTRACT In this book chapter, the authors discuss some important communication issues to obtain a highly scalable computing system. They consider the CGM (Coarse-Grained Multicomputer) model, a realistic computing model to obtain scalable parallel algorithms. The communication cost is modeled by the number of communication rounds and the objective is to design algorithms that require the minimum number of communication rounds. They discuss some important issues and make considerations of practical importance, based on our previous experience in the design and implementation of parallel algorithms. The first issue is the amount of data transmitted in a communication round. For a practical implementation to be successful they should attempt to minimize this amount, even when it is already within the limit allowed by the CGM model. The second issue concerns the trade-off between the number of communication rounds which the CGM attempts to minimize and the overall communication time taken in the communication rounds. Sometimes a larger number of communication rounds may actually reduce the total amount of data transmitted in the communications rounds. These two issues have guided us to present efficient parallel algorithms for the string similarity problem, used as an illustration.
DOI: 10.4018/978-1-60566-661-7.ch017
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Communication Issues in Scalable Parallel Computing
INTRODUCTION In this book chapter, we discuss some important communication issues to obtain a highly scalable computing system. Scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged. We consider the CGM (Coarse-Grained Multicomputer) model, a realistic computing model to obtain scalable parallel algorithms. A CGM algorithm that solves a problem of size n with p processors each with O(n/p) memory consists of an alternating sequence of computation rounds and communication rounds. In one communication round, we allow the exchange of O(n/p) data among the processors. The communication cost is modeled by the number of communication rounds and the objective is to design algorithms that require the minimum number of communication rounds. We discuss some important issues and make considerations of practical importance, based on our previous experience in the design and implementation of several parallel algorithms. The first issue is the amount of data transmitted in a communication round. For a practical implementation to be successful we should attempt to minimize this amount, even when it is already within the maximum allowed by the CGM model which is O(n/p). The second issue concerns the trade-off between the number of communication rounds which the CGM attempts to minimize and the overall communication time taken in the communication rounds. Under the CGM model we want to minimize the number of communication rounds so that we do not have to care about the particular interconnection network. In a practical implementation, we do have more information concerning the hardware utilized and the communication times in a particular interconnection network. Sometimes a larger number of communication rounds may actually reduce the total amount of data transmitted in the communications rounds. Although the goal of the CGM model is to minimize the number of communication rounds, ultimately the main objective is to minimize the overall running time that includes the computation and the communication times. These two issues have guided us to present efficient parallel algorithms for the string similarity problem, used as an illustration. By using the wavefront-based algorithms we present in this book chapter to illustrate these two issues, we also address a third issue, the desirability of avoiding costly global communication such as broadcast and all-to-all primitives. This is obtained by using wavefront or systolic parallel algorithms where each processor communicates with only a few other processors. The string similarity problem is presented here as an illustration. This problem is interesting in its own right. Together with many other important string processing problems (Alves et al., 2006), string similarity is a fundamental problem in Computational Biology that appears in more complex problems (Setubal & Meidanis, 1997), such as the search of similarities between bio-sequences (Needleman & Wunsch, 1970; Sellers, 1980; Smith & Waterman, 1981). We show two wavefront parallel algorithms to solve the string similarity problem. We implement both the basic algorithm (Alves et al., 2002) and the improved algorithm (Alves et al., 2003) by taking into consideration the communication issues discussed in this book chapter and obtain very efficient and scalable solutions.
PARALLEL COMPUTATION MODEL Valiant (1990) introduced a simple coarse grained parallel computing model, called Bulk Synchronous Parallel Model – BSP. It gives reasonable predictions on the performance of the algorithms when
379
Communication Issues in Scalable Parallel Computing
implemented on existing, mainly distributed memory, parallel machines. It is also one of the earliest models to consider communication costs and to abstract the characteristics of parallel machines with a few parameters. The main objective of BSP is to serve a bridging model between the hardware and software necessities. This is one of the fundamental characteristics for the success of the von Neumann model. In the BSP model, parallel computation is modeled by a series of super-steps. In this model, p processors with local memory communicate through some interconnection network managed by a router with global synchronization. A BSP algorithm consists of a sequence of super-steps separated by synchronization barriers. In a super-step, each processor executes a set of independent operations using local data available in each processor at the start of the super-step, as well as communication consisting of send and receive of messages. An h-relation in a super-step corresponds to sending or receiving at most h messages in each processor. The response to a message sent in one super-step can only be used in the next super-step. In this paper we use a similar model called the Coarse Grained Multicomputers – (denoted by BSP/ CGM), proposed by Dehne et al. (1993). A BSP/CGM consists of a set of p processors P1, P2,…,Pp with O(n/p) local memory per processor and each processor is connected through any interconnection network. The term coarse granularity comes from the fact that the problem size in each processor n/p is considerably larger than the number of processors, that is, n/p>>p. A BSP/CGM algorithm consists of alternating local computation and global communication rounds separated by a barrier synchronization. The BSP/CGM model uses only two parameters: the input size n and the number of processors p. In a computing round, each processor runs a sequential algorithm to process its data locally. A communication round consists of sending and receiving messages, in such a way that each processor sends at most O(n/p) data and receives at most O(n/p) data. We require that all information sent from a given processor to another processor in one communication round is packed into one long message, thereby minimizing the message overhead. In the BSP/CGM model, the communication cost is modeled by the number of communication rounds which we wish to minimize. In a good BSP/CGM algorithm the number of communication rounds does not depend on the input size n. The ideal algorithm requires a constant number of communication rounds. If this is not possible, we attempt to get an algorithm for which this number is independent on n but depends on p. This is the case of the present chapter. The BSP/CGM model has the advantage of producing results are close to the actual performance of commercially available parallel machines. Some algorithms for computational geometry and graph problems require a constant number or O(log p) communication rounds (e.g. see Dehne et al. (1993)). The BSP/CGM model is particularly suitable for current parallel machines in which the global computing speed is considerably greater than the global communication speed. One way to explore the use of parallel computation can be through the use of clusters of workstations or Fast/Gigabit Ethernet connected Linux-based Beowulf machines, with Parallel Virtual Machine PVM or Message Passing Interface - MPI libraries. The latency in such clusters or Beowulf machines of 1Gb/s is currently less than 10 μs and programming using these resources is today a major trend in parallel and distributed computing. Though much effort has been expended to deal with the problems of interconnection of clusters or Beowulfs and the programming environment, there is still few works on methodologies to design and analyze algorithms for scalable parallel computing systems.
380
Communication Issues in Scalable Parallel Computing
Figure 1. String alignment examples
THE STRING SIMILARITY PROBLEM In Molecular Biology, the search for tools that identify, store, compare and analyze very long bio-sequences is becoming a major research area in Computational Biology. In particular, sequence comparison is a fundamental problem that appears in more complex problems (Setubal & Meidanis, 1997), such as the search of similarities between bio-sequences (Needleman & Wunsch, 1970; Sellers, 1980; Smith & Waterman, 1981), as well as in the solution of several other problems such as approximate string matching, file comparison, and text searching with errors (Hall & Dowling, 1980; Hunt & Szymansky, 1977; Wu & Manber, 1992). One main motivation for biological sequence comparison, in particular proteins, comes from the fact that proteins that have similar tri-dimensional forms usually have the same functionality. The tridimensional form is given by the sequence of symbols that constitute the protein. In this way, we can guess a functionality of a new protein by searching a known protein that is similar to it. In this section we present the string similarity problem. One way to identify similarities between sequences is to align them, with the insertion of spaces in the two sequences, in such way that the two sequences become equal in length. We expect that the alignment of two sequences that are similar will show the parts where they match, and different parts where spaces are inserted. We are interested in the best alignment between two strings, and the score of such an alignment gives a measure of how much the strings are similar. The similarity problem is defined as follows. Let A = a1a2…am and C = c1c2…cn be two strings over some alphabet. To align the two strings, we insert spaces in the two sequences in such way that they become equal in length. See Figure 1 where each column consists of a symbol of A (or a space) and a symbol of C (or a space). An alignment between A and C is a matching of the symbols a A and c C in such way that if we draw lines between the corresponding matched symbols, these lines cannot cross each other. The alignment shows the similarities between the two strings. Figure 1 shows two simple alignment examples where we assign a score of 1 when the aligned symbols in a column match and 0 otherwise. The alignment on the right has a higher score (5) than that on the left (3). A more general score assignment for a given alignment between strings is done as follows. Each column of the alignment receives a certain value depending on its contents and the total score for the alignment is the sum of the values assigned to its columns. Consider a column consisting of symbols r and s. If r = s (i.e. a match), it will receive a value p(r, s) > 0. If r ≠ s (a mismatch), the column will receive a value p(r , s ) < 0 . Finally, a column with a space in it receives a value −k, where k N . We look for the alignment (optimal alignment) that gives the maximum score. This maximum score is called the similarity measure between the two strings to be denoted by sim(A,C) for strings A and C. There may
381
Communication Issues in Scalable Parallel Computing
Figure 2. Grid DAG G for A= baabcbca and B = baabcabcab
be more than one alignment with maximum score (Setubal & Meidanis, 1997). Dynamic programming is a technique used in the solution of many optimization and decision problems. It decomposes the problem into a sequence of optimization or decision steps that are interconnected and are solved one after another. The optimal solution of the problem is obtained by the decomposition of the problem in sub-problems, and computing the optimal solution for each sub-problem. By combining these solutions we obtain the optimal solution of the global problem. Differently from the other optimization methods, such as linear programming and branch and bound, dynamic programming is not a general technique. Optimization problems should be translated into a more specific form before dynamic programming can be used. This translation can be very difficult. This constitutes a further difficulty in addition to the need of formulating the problem to be solved efficiently by the dynamic programming approach. Consider two strings A and C, where |A| = m and |C| = n. We can solve the string similarity problem by computing all the similarities between arbitrary prefixes of the two strings starting with the shorter prefixes and use previously computed results to solve the problem for larger prefixes. There are m + 1 possible prefixes of A and n + 1 prefixes of C. Thus, we can arrange our calculations in an (m + 1) × (n +1) matrix S where each S(r,s) represents the similarity between A[1..r] and C[1..s], that denote the prefixes a1a2…ar and c1c2…cs, respectively. Observe that we can compute the values of S(r,s) by using the three previous values S(r – 1,s), S(r – 1,s – 1) and S(r, s – 1), because there are only three ways to compute an alignment between A[1..r] and C[1..s]. We can align A[1..r] with C[1..s – 1] and match a space with C[s], or align A[1..r – 1] with C[1..s – 1] and match A[r] with B[s], or align A[1..r – 1] with C[1..s] and match a space with A[r]. (Figure 2)
Figure 3. The recursive definition of the similarity score
382
Communication Issues in Scalable Parallel Computing
The similarity score S of the alignment between strings A and C can be computed as in Figure 3. An l1 × l2 grid DAG (Figure 2) is a directed acyclic graph whose vertices are the l1l2 points of an l1 × l2 grid, with edges from grid point G(i, j) to the grid points G(i, j + 1), G(i + 1, j) and G(i + 1, j + 1). Let A and C be two strings with |A| = m and |C| = n symbols, respectively. We associate an (m + 1) × (n + 1) grid DAG G with the similarity problem in the natural way: the (m + 1)(n + 1) vertices of G are in one-to-one correspondence with the (m + 1)(n + 1) entries of the S-matrix, and the cost of an edge from vertex (t, l) to vertex (i, j) is equal to k if t = i and l = j – 1 or if t = i – 1 and l = j; and to p(i, j) if t = i – 1 and l = j – 1. It is easy to see that the string similarity problem can be viewed as computing the minimum sourcesink path in a grid DAG. In Figure 2 the problem is to find the minimum path from (0,0) to (8,10). A sequential algorithm to compute the similarity between two strings of lengths m and n uses a technique called dynamic programming. The complexity of this algorithm is O(mn). The construction of the optimal alignment can be done in sequential time O(m + n) (Setubal & Meidanis, 1997). PRAM (Parallel Random Access Machine) algorithms for the dynamic programming problem have been obtained by Galil and Park (1991). PRAM algorithms for the string editing problem have been proposed by Apostolico et al. (1990). A more general study of parallel algorithms for dynamic programming can be seen in (Gengler, 1996). We present two algorithms that use the realistic BSP/CGM model. A characteristic and advantage of the wavefront or systolic algorithm is the modest communication requirement, with each processor communicating with few other processors. This makes it very suitable as a potential application for grid computing where we wish to avoid costly global communication operations such as broadcast and all-to-all operations.
THE BASIC SIMILARITY ALGORITHM The basic similarity algorithm is due to Alves et al. (2002). It is a BSP/CGM algorithm and attempts to minimize the number of communication rounds. Consider two given strings A = a1a2…am and C = c1c2…cn. The basic similarity algorithm computes the similarity between A and C on a CGM/BSP with p processors and mn/p local memory in each processor. We divide C into p pieces, of size n/p, and each processor Pi, 1 ≤ i ≤ p, receives the string A and the i-th piece of C ( c (i - 1)n / p + 1,..., cin / p ). Each processor Pi computes the elements Si(r, s) of the submatrix Si, where 1 ≤ r ≤ m and (i - 1)n / p + 1 £ s £ in / p using the three previous elements S (r – 1,s), S (r – 1, s – 1) and S (r, s – 1), i
i
i
because, as mentioned before, there are only three ways of computing an alignment between A[1..r] and C[1..s]. We can align A[1..r] with C[1..(s – 1)] and match a space with C[s], or align A[1..(r – 1)] with C[1..(s – 1)] and match A[r] with B[s], or align A[1..(r – 1)] with C[1..s] and match a space with A[r]. To compute the submatrix Si, each processor Pi uses the best sequential algorithm locally. It is easy to see that processor Pi, i > 1, can only start computing the elements Si(r, s) after the processor Pi– 1 has computed part of the submatrix Si– 1 (r, s). Denote by Rik, 1 ≤ i, k ≤ p, all the elements of the right boundary (rightmost column) of the k-th part of the submatrix Si. More precisely, Rik = {Si(r, in/p,(k – 1)m/p + 1 ≤ r ≤ km/p}.
383
Communication Issues in Scalable Parallel Computing
Figure 4. An O(p) communication rounds scheduling used in the basic algorithm
The idea of the algorithm is the following: After computing the k-th part of the submatrix Si, processor Pi sends to processor Pi+ 1 the elements of Rik . Using Rik, processor Pi+ 1 can compute the k-th part of the submatrix Si+ 1. After p – 1 rounds, processor Pp receives Rp-11 and computes the first part of the submatrix Sp. At round 2p – 2, processor Pp receives Rp-1p and computes the p-th part of the submatrix Sp and finishes the computation. Using this schedule (Figure 4), we can see that in the first round, only processor P1 works. In the second round, processors P1 and P2 work. It is easy to see that in round k, all processors Pi work, where 1 ≤ i ≤ k. We now present the basic string similarity algorithm.Basic Similarity Algorithm (see Figure 5). Theorem 1. The basic similarity algorithm uses 2p – 2 communication rounds with O(mn/p) sequential computing time in each processor. Proof. Processor P1 sends R1k to processor P2 after computing the k-th block of m/p rows of the mn/p subFigure 5. The basic similarity algorithm
384
Communication Issues in Scalable Parallel Computing
Figure 6. Table of running times of the basic algorithm for various string lengths
matrix S1. After p – 1 communication rounds, processor P1 finishes its work. Similarly, processor P2 finishes its work after p communication rounds. Then, after p – 2 + i communication rounds, processor Pi finishes its work. Since we have p processors, after 2p – 2 communication rounds, all the p processors have finished their work. Each processor uses a sequential algorithm to compute the similarity submatrix Si. Thus this algorithm takes O(mn/p) computing time. Theorem 2. At the end of the basic similarity algorithm, S(m, n) will store the score of the similarity between the strings A and C. Proof. By Theorem 1, after 2p – 2 communication rounds, processor Pp finishes its work. Since we are essentially computing the similarity sequentially in each processor and sending the boundaries to the right processor, the correctness of the algorithm comes naturally from the correctness of the sequential algorithm. Then, after 2p – 2 communication rounds, S(m, n) will store the similarity between the strings A and C.
Experimental Results of the Basic Algorithm In this section we present the experimental results of the basic similarity algorithm. The following figures give running time curves. We have implemented the O(p) rounds basic similarity algorithm on a Beowulf with 64 nodes. Each node has 256 MB of RAM memory and more 256 MB for swap. The nodes are connected through a 100 MB interconnection network.
385
Communication Issues in Scalable Parallel Computing
Figure 7. Curves of the observed times for various string lengths
Figure 8. Curves of the observed times for various string lengths
386
Communication Issues in Scalable Parallel Computing
Figure 9. An O(p) communication rounds scheduling with α= 1
The obtained times (Figures 6, 7 and 8) show that with small sequences, the communication time is significant when compared to the computation time with more than 8 and 16 processors, respectively (512 × 512 and 512 × 1024). When we apply the algorithm to sequences greater than 8192, using one or two processors, the main memory is not enough to solve the problem. The utilization of swap gives us meaningless resulting times. This would not occur if the nodes have more main memory. Thus we have suppressed these times. In general, the implementation of the CGM/BSP algorithm shows that the theoretical results are confirmed in the implementation. The basic similarity algorithm requires O(p) communication rounds to compute the score of the similarity between two strings. We have worked with a fixed block size of m/p × n/p. Another good alternative is to work with adaptative choice of the optimal block size to further decrease the running time of the algorithm. The alignment between the two strings can be obtained with O(p) communication rounds backtracking from the lower right corner of the grid graph in O(m + n) time (Setubal & Meidanis, 1997). For this, S(r, s) for all points of the grid graph must be stored during the computation (requiring O(mn) space).
THE IMPROVED SIMILARITY ALGORITHM Alves et al. (2003) extend and improve the basic similarity algorithm (Alves et al., 2002) for computing an alignment between two strings A and C, with A =|m| and C =|n|. On a distributed memory parallel computer of p processors each with O((m + n) / p) memory, the improved algorithm also requires O(p) communication rounds, more precisely (1 + 1 / α)p – 2 communication rounds where α is a parameter to be presented shortly, and O(mn / p) local computing time. As in the basic algorithm, the processors communicate in a wavefront or systolic manner, such that each processor communicates with few other processors. Actually each processor sends data to only two other processors. The novelty of the improved similarity algorithm is based on a compromise between the workload of each processor and the number of communication rounds required, expressed by a parameter called α. The proposed algorithm is expressed in terms of this parameter that can be tuned to obtain the best overall parallel time in a given implementation. In addition to showing theoretic complexity we confirm the efficiency of the proposed algorithm through implementation. As will be seen shortly, very promising experimental results are obtained on a 64-node Beowulf machine. We present a parameterized O(p) communication rounds parallel algorithm for computing the simi-
387
Communication Issues in Scalable Parallel Computing
Figure 10. An O(p) communication rounds scheduling with α = 1/2
larity between two strings A and C, over some alphabet, with |A|= m and |C|= n. We use the CGM/BSP model with p processors, where each processor has O(mn / p) local memory. As will be seen later, this can be reduced to O((m + n) / p). Let us first give the main idea to compute the similarity matrix S by p processors. The string A is broadcasted to all processors, and the string C is divided into p pieces, of size n / p, and each processor Pi, 1 ≤ l ≤ p, receives the i-th piece of C ( c (i - 1)n / p + 1...cin / p ). The scheduling scheme is illustrated in Figure 9. The notation Pik denotes the work of Processor Pi at round k. Thus initially P1 starts computing at round 0. Then P1 and P2 can work at round 1, P1, P2 and P3 at round 2, and so on. In other words, after computing the k-th part of the sub-matrix Si (denoted Sik), processor Pi sends to processor Pi+ 1 the elements of the right boundary (rightmost column) of Sik. These elements are denoted by Rik. Using Rik, processor Pi + 1 can compute the k -th part of the sub-matrix Si+ 1. After p – 1 rounds, processor Pp receives Rp-11 and computes the first part of the sub-matrix Sp. In round 2p – 2, processor Pp receives Rp-1p and computes the p-th part of the sub-matrix Sp and finishes the computation.
Figure 11. The improved similarity algorithm
388
Communication Issues in Scalable Parallel Computing
It is easy to see that with this scheduling, processor Pp only initiates its work when processor P1 is finishing its computation, at round p – 1. Therefore, we have a very poor load balancing. In the following we attempt to assign work to the processors as soon as possible. This can be done by decreasing the size of the messages that processor Pi sends to processors Pi+ 1. Instead of message size m / p we consider sizes α m / p and explore several sizes of α. In our work, we make the assumption that the sizes of the messages α m / p divides m. Therefore, Sik (the similarity sub-matrix computed by processor Pi at round k) represents k α m / p + 1 to (k + 1) α m / p rows of Si that are computed at the k-th round. We now present the improved similarity algorithm. The improved algorithm works as follow: After computing Sik, processor Pi sends Rik to processor Pi+ 1. Processor Pi+ 1 receives Rik from Pi and computes Si+1k+1. After p – 2 rounds, processor Pp receives Rp-1p-2 and computes Spp-1. If we use α < 1 all the processors will work simultaneously after the p – 2-th round. We explore several values for α trying to find a balance between the workload of the processors and the number of rounds of the algorithms. Figure 10 shows how the algorithm works when α = 1/2. In this case, processor Pp receives Rp-13p-3, computes Sp3p-2 and finishes the computation. Improved Similarity Algorithm (see Figure 11). Using the schedule of Figure 10, we can see that in the first round, only processor P1 works. In the second round, processors P1 and P2 work. It is easy to see that at the k-th round, all processors Pi work, where 1 ≤ i ≤ k. Since the total number of rounds is increased with smaller values of α the processors start working earlier. Theorem 3 The improved algorithm uses (1 + 1 / α)p – 2 communication rounds with mn / p sequential computing time in each processor. Proof: Processor P1 sends R1k to processor P2 after computing the k-th block of α m / p rows of the mn / p sub-matrix S1. After p / α – 1 communication rounds, processor P1 finishes its work. Similarly, processor P finishes its work after p / a communication rounds. Then, after p / α – 2 + i communication rounds, 2
processor Pi finishes its work. Since we have p processors, after (1 + 1 / α)p – 2 communication rounds, all the p processors have finished their work. Each processor uses a sequential algorithm to compute the similarity sub-matrix Si. Thus this algorithm takes O(mn / p) computing time. Theorem 4 At the end of the improved algorithm, S(m, n) will store the score of the similarity between the strings A and C.
389
Communication Issues in Scalable Parallel Computing
Figure 12. Table showing running times for various values of αwith m=8K and n=16K
Proof: Theorem 3 proves that after (1 + 1 / α)p – 2 communication rounds, processor Pp finishes its work. Since we are essentially computing the similarity sequentially in each processor and sending the boundaries to the right processor, the correctness of the algorithm comes naturally from the correctness of the sequential algorithm. Then, after (1 + 1 / α)p – 2 communication rounds, S(m, n) will store the similarity between the strings A and C.
Figure 13. Time curves vs. number of processors with m=8K and n=16K
390
Communication Issues in Scalable Parallel Computing
Figure 14. Time curves vs. values of α with m=8K and n=16K
Figure 15. Table showing running times for various values of α with m=4K and n=8K
Figure 16. Time curves versus number of processors with m=4K and n=8K
391
Communication Issues in Scalable Parallel Computing
Figure 17. Curves of the observed times - quadratic space
Experimental Results of the Improved Similarity Algorithm In this section we present the experimental results of the improved similarity algorithm. We have implemented the improved similarity algorithm on a Beowulf with 64 nodes. Each node has 256 MB of RAM memory in addition to 256 MB for swap. The nodes are connected through a 100 MB interconnection network. Figures 12, 13 and 14 show the running times of the improved similarity algorithm for different values of α for string lengths of m=8K and n=16K. For a given experiment and hardware platform a parameter tuning phase is required to obtain the best value for α. Figures 12, 13 and 14 show running times for string sizes m =8K and n =16K where K=1024. It can be seen that, for very small α, the communication time is significant when compared to the computation time. We have analyzed the behavior of α to estimate the optimal block size. The observed times show that when α m / p decreases from 16 to 8 (the number of rows of the sub-matrix Si(k)), we have an increase on the total time. The best times are obtained for α between 1/4 and 1/8. Figures 15 and 16 show the running times of the improved similarity algorithm for different values
Figure 18. Curves of the observed times - linear space
392
Communication Issues in Scalable Parallel Computing
of α for string lengths of m=4K and n=8K. Again, for a given experiment and hardware platform a parameter tuning phase is required to obtain the best value for α.
quadratic vs. Linear Space Implementation We can further improve our results by exploring a linear space implementation, by storing a vector instead of the entire matrix. In the usual quadratic space implementation, each processor uses O(mn / p) space, while in the linear space implementation each processor requires only O((m + n) / p) space. The results are impressive, as shown in Figures 17 and 18. With less demand on the swap of disk space, we get an almost 50% improvement. We have used α=1.
CONCLUSION We have presented a basic and an improved parameterized BSP/CGM parallel algorithm to compute the score of the similarity between two strings. On a distributed memory parallel computer of p processors each with O((m + n) / p) memory, the proposed algorithm requires O(p) communication rounds and O(mn / p) local computing time. The novelty of the improved similarity algorithm is based on a compromise between the workload of each processor and the number of communication rounds required, expressed by a new parameter called α. We have worked with a variable block size of α m / p × n / p and studied the behavior of the block size. We show how this parameter can be tuned to obtain the best overall parallel time in a given implementation. Very promising experimental results are shown. Though we dedicated considerable space to present the two string similarity algorithms, these algorithms serve the purpose of illustrating two main issues. The first issue is the amount of data transmitted in a communication round. For a practical implementation to be successful we should attempt to minimize this amount, even when it is already within the limit allowed by the CGM model. The second issue concerns the trade-off between the number of communication rounds which the CGM attempts to minimize and the overall communication time taken in the communication rounds. Sometimes a larger number of communication rounds may actually reduce the total amount of data transmitted in the communications rounds. To this end the parameter α is introduced in the improved similarity algorithm. By adjusting the proper value of α, we can actually require more communication rounds while diminishing the total amount of data transmitted in the communication rounds, thus resulting in a more efficient solution. As a final observation notice that a characteristic of the wavefront communication requirement is that each processor communicates with few other processors. This makes it very suitable as a potential application for grid computing.
REFERENCES Alves, C. E. R., Caceres, E. N., Dehne, F., & Song, S. W. (2002). A CGM/BSP Parallel Similarity Algorithm. In Proceedings I Brazilian Workshop on Bioinformatics (pp. 1-8). Porto Alegre: SBC Computer Society.
393
Communication Issues in Scalable Parallel Computing
Alves, C. E. R., Caceres, E. N., Dehne, F., & Song, S. W. (2003). A Parallel Wavefront Algorithm for Efficient Biological Sequence Comparison. In Kumar, M. L. Gavrilva, C. J. K. Tan, & P. L’Ecuyer (Eds.). The 2003 International Conference on Computational Science and its Applications. (LNCS Vol. 2668, pp. 249-258). Berlin: Springer Verlag. Alves, C. E. R., Caceres, E. N., & Song, S. W. (2006). A coarse-grained parallel algorithm for the allsubstrings longest common subsequence problem. Algorithmica, 45(3), 301–335. doi:10.1007/s00453006-1216-z Apostolico, A., Atallah, M. J., Larmore, L. L., & Macfaddin, S. (1990). Efficient parallel algorithms for string editing and related problems. SIAM Journal on Computing, 19(5), 968–988. doi:10.1137/0219066 Dehne, F. (1999). Coarse grained parallel algorithms. Algorithmica, 24(3/4), 173–176. Dehne, F., Fabri, A., & Rau-Chaplin, A. (1993). Scalable parallel geometric algorithms for coarse grained multicomputers. In Proceedings ACM 9th Annual Computational Geometry (pp. 298-307). Galil, Z., & Park, K. (1991). Parallel dynamic programming (Tech. Rep. CUCS-040-91). New York: Columbia University, Computer Science Department. Gengler, M. (1996). An introduction to parallel dynamic programming. In Solving Combinatorial Optimization Problems in Parallel. (LNCS Vol. 1054 pp. 87-114). Berlin: Springer Verlag. Hall, P. A., & Dowling, G. R. (1980). Approximate string matching. Comput. Surveys, 12(4), 381–402. doi:10.1145/356827.356830 Hunt, J. W., & Szymansky, T. (1977). An algorithm for differential file comparison. Communications of the ACM, 20(5), 350–353. doi:10.1145/359581.359603 Needleman, S. B., & Wunsch, C. D. (1970). A general method applicable to the search for similarities in the amino acid sequence of two proteins. Journal of Molecular Biology, 48(3), 443–453. doi:10.1016/00222836(70)90057-4 Sellers, P. H. (1980). The theory and computation of evolutionary distances: Pattern recognition. Journal of Algorithms, (4): 359–373. doi:10.1016/0196-6774(80)90016-4 Setubal, J., & Meidanis, J. (1997). Introduction to computational molecular biology. Boston: PWS Publishing Company. Smith, T. F., & Waterman, M. S. (1981). Identification of common molecular subsequences. J. Mol. Bio. (147), 195-197. Valiant, L. (1990). A bridging model for parallel computation. Communications of the ACM, 33(8), 103–111. doi:10.1145/79173.79181 Wu, S., & Manber, U. (1992). Fast text searching allowing errors. Communications of the ACM, 35(10), 83–91. doi:10.1145/135239.135244
394
Communication Issues in Scalable Parallel Computing
KEY TERMS AND DEFINITIONS Coarse-Grained Multicomputer: A simple and realistic parallel computing model, characterized by two parameters (input size n and number of processors p), in which local computation rounds alternate with global communication rounds, with the goal of minimizing the number of communication rounds. Granularity: A measure of the size of the components, or descriptions of components, that make up a system. In parallel computing, granularity refers to the amount of computation that can be performed by the processors before requiring a communication stepto exchange data. Scalability: A desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged. String Similarity Metrics: Textual based metrics resulting in a similarity or dissimilarity (distance) score between two pairs of text strings for approximate matching or comparison. Systolic Algorithm: An algorithm that has the characteristics of a systolic array. Systolic Array: A pipelined network of processing elements called cells, used in parallel computing, where cells compute data and store it independently of each other and passes the computed data to neighbor cells. Wavefront Algorithm: An algorithm that has the characteristics of a systolic array, also known as systolic algorithm.
ENDNOTE 1
Partially supported by FAPESP Proc. No. 2004/08928-3, CNPq Proc. No. 55.0094/05-9, 55.0895/07-8, 30.5362/06-2, 30.2942/04-1, 62.0123/04-4, 48.5460/06-8, FUNDECT 41/100.115/2006, and the Natural Sciences and Engineering Resarch of Canada.
395
396
Chapter 18
Scientific Workflow Scheduling with TimeRelated QoS Evaluation Wanchun Dou Nanjing University, P. R. China Jinjun Chen Swinburne University of Technologies, Australia
ABSTRACT This chapter introduces a scheduling approach for cross-domain scientific workflow execution with timerelated QoS evaluation. Generally, scientific workflow execution often spans self-managing administrative domains to achieving global collaboration advantage. In practice, it is infeasible for a domain-specific application to disclose its process details for privacy or security reasons. Consequently, it is a challenging endeavor to coordinate scientific workflows and its distributed domain-specific applications from service invocation perspective. Therefore, in this chapter, the authors aim at proposing a collaborative scheduling approach, with time-related QoS evaluation, for navigating cross-domain collaboration. Under this collaborative scheduling approach, a private workflow fragment could maintain temporal consistency with a global scientific workflow in resource sharing and task enactments. Furthermore, an evaluation is presented to demonstrate the scheduling approach.
INTRODUCTION In the past few years, some computing infrastructures, e.g., grid infrastructure, have been emerged for accommodating powerful computing and for enhancing resource sharing capabilities required by crossorganizational workflow application (Wieczorek, 2005; Fox, 2006). It is a new special type of workflow that often underlies many large-scale complex e-science applications such as climate modeling, structural biology and chemistry, medical surgery or disaster recovery simulation (Ludäscher, 2005; Bowers, 2008; Zhao, 2006). This new type of scientific workflow applications is gaining more and more momentums due to their key role in e-Science and cyber-infrastructure applications. As scientific workflows are typically DOI: 10.4018/978-1-60566-661-7.ch018
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Scientific Workflow Scheduling with Time-Related QoS Evaluation
data-centric and dataflow-oriented “analysis pipelines” (Ludäscher, 2005; McPhillips, 2005), scientists often need to “glue” together various cross-domain services such as cross-organizational data management, analysis, simulation, and visualization services (Yan, 2007; Rygg, 2008). Compared with business workflows, scientific workflows have special features such as computation, data or transaction intensity, less human interactions, and a larger number of activities (Wieczorek, 2005). Accordingly, scientific workflow applications frequently require collaborative patterns marked by multiple domain-specific applications from different organizations. An engaged domain-specific application often contributes a definite local computing goal to global scientific workflow execution. Typically, in this loose coupled application environment, goal-specific scientists are rather individualistic and more likely to create their own “knowledge discovery workflow” by taking advantage of available services (Ludäscher, 2005). It promotes scientific collaboration in form of service invocation for achieving certain computing goals. To facilitate scientific workflow’s development and execution, cross-domain workflow modeling and scheduling are key topics that currently cause more and more attentions (Wieczorek, 2005; Yan, 2007;Yu, J., & Buyya, R., 2005;Yu, J., Buyya, R., & Tham, C. K., 2005). For example, Yu and Buyya (Yu, J., & Buyya, R., 2005) provided a general taxonomy of scientific workflow, in which workflow design, workflow scheduling, fault tolerance, and data movement are four key features associated with the development and execution of a scientific workflow management system in Grid environment. Furthermore, they believed that a scientific workflow paradigm could greatly enhance scientific collaboration through spanning multiple administrative domains to obtain specific processing capabilities. Here, scientific collaborations are often navigated by data-dependency and temporal-dependency relations among goal-specific domain applications, in which a domain-specific application is often implemented as a local workflow fragment deployed inside a self-managing organization for providing the demanded services in time. In a grid computing infrastructure, a service for scientific collaboration is often called a grid service that address resource discovery, security, resource allocation, and other concerns (Foster, 2001). For crossorganizational collaboration, existing (global) analysis techniques often mandate every domain-specific service to unveil all individual behaviors for scientific collaboration (Chiu, 2004). Unfortunately, such an analysis is infeasible when a domain-specific service refuses to disclose its process details for privacy or security reasons (Dumitrescu, 2005; Liu, 2006). Therefore, it is always a challenging endeavor to coordinate a scientific workflow and its distributed domain-specific applications (local workflow fragments for producing domain-specific service), especially when a local workflow fragment is engaged in different scientific workflow executions in a concurrent environment. Generally, a local workflow fragment for producing domain-specific service is often deployed inside a self-governing organization, which could be treated as a private workflow fragment of the self-governing organization. In this situation, to effectively coordinate internal service performances and external service invocation, as well as their quality, collaborative scheduling between a scientific workflow and engaged self-managing organizations may be greatly helpful for promoting the interactions of independent local applications with the higher-level global application. It aims at coordinating executions for computationand data-rich scientific collaboration in a readily available way. For example, resource management in Grid environment is typically subject to individual access, accounting, priority, and security policies of the resource owner. Resource sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs in form of service. The usage policy imposing on these resources is often enforced by a self-managing organization (Foster, 2001; Batista, 2008). At runtime, if a selfmanaging organization refuses to disclose its process details for privacy or security reasons, the resource
397
Scientific Workflow Scheduling with Time-Related QoS Evaluation
service process is often promoted by a resource-broker (Abramsona, 2002; Elmroth, 2008). Besides, if a resource could not be shared by different resource users at the same time, executions of different scientific workflow around these resources should coordinate their resource sharing in a compromising way. Otherwise, some conflicts would be occurred during the execution. Therefore, cross-organizational scientific workflow execution, resource allocation, and compromising usage policy should be scheduled in an incorporated way in a concurrent environment (Yan, 2007; Li, 2006). For instance, a computing center is a typical self-managing organization that often bears up heavy computing loads from numerous goal-specific applications. The scheduling of a computing center for satisfying its multi external service requirements is a typical coordinative process between a scientific workflow and a self-managing organization. Resource compromising usage policy is often recruited for coordinating its computational resource’s using processes engaged in different scientific collaborations in a concurrent environment. Additionally, for a performance-driven scientific workflow execution, collaborative scheduling process is a more complex situation as a collaborative scheduling process not only covers cross-organizational resource sharing, but also covers task enactments deployed inside self-managing organizations (Yan, 2007; Batista, 2008), which is often initiated by domain-specific service specifications and its application context specifications. In view of these observations, a collaborative scheduling approach is investigated, in this paper, for achieving coordinated executions of a scientific workflow with time-related QoS evaluation. It is specifically deployed in a Grid environment. Taking advantage of the collaborative scheduling strategy, a private workflow fragment could maintain its temporal consistency with a scientific workflow in resource sharing and task enactments. Please note that our method subscribes to relative time rather than absolute time in collaborative scheduling applications. The rest of this chapter is organized as follows. In Section 2, some preliminary knowledge of QoS is presented for piloting our further discussion. In Section 3, a temporal model of service-driven scientific workflow execution is investigated. In section 4, application context analyses of scientific workflow execution is discussed. In Section 5, taking advantage of the temporal model presented in Section 3 and the context analysis presented in Section4, a temporal reasoning rule is put forward for collaboration scheduling application of a scientific workflow. In Section 6, an evaluation is proposed for demonstrating our approach presented in this paper. In Section 7, related works and comparison analysis are presented to evaluate the feasibility of our proposal. Finally, the conclusions and our future work are presented in Section 8.
PRELIMINARY KNOWLEDGE OF qOS With recent advances in pervasive devices and communication technologies, there are increasing demands in scientific and engineering application for ubiquitous access to networked services. These services extend supports from Web browsers on personal computers to handheld devices and sensor networks. Generally, a service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. Service-Oriented Architecture (SOA) is essentially a collection of services. These services communicate with each other and the communication can involve either simple data passing or it could involve two or more services for coordinating some activity (http://www.servicearchitecture.com/). Figure 1 illustrates a general style of the service-oriented scenario. In Fig.1, a service consumer sends a service request to a service provider, and the service provider returns a response to the service con-
398
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 1. Service-oriented scenario between service consumer and service provider
sumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. Here, the service could be reified into a unit of work done by a service provider to achieve desired goal for a service consumer. Here, both service provider and service consumer could be roles played by software agents on behalf of their owners. Service-oriented applications are most launched by this Web service invocation style as illustrated by Fig.1. Generally, Web services are self-contained business applications, which can be published, located and invoked by other applications over the Internet. Different vendors, research firms and standards organizations could define their Web services differently, however the common theme in all these definitions is that Web services are loosely coupled, dynamically bound, accessed over the web and standards based. Web services often use XML schema to create a robust connection. They are based on strict standard specifications to work together and with other similar kinds of applications. More specifically, Web services are based on three key standards in their current manifestation, i.e., SOAP (XML-based message format), WSDL (XML-based Web Services Description Language), and UDDI (XML-based Universal Description, Discovery, and Integration of Web Services). Any use of these basic standards constitutes a Web service. Universal, platform independent connectivity (via XML-based SOAP messages) and self-describing interfaces (through WSDL) characterize the Web services, and UDDI is the foundation for a dynamic repository which provides the means to locate appropriate Web Services. The typical Web Service invocation is demonstrated by Fig.2, by taking advantage of those standards. Web services allows for the development of loosely coupled solutions. The independent resources expose an interface, which can be accessed over the network. For example, a firm may expose a particu-
Figure 2. A typical Web service invocation paradigm in technology
399
Scientific Workflow Scheduling with Time-Related QoS Evaluation
lar application as a service, which would allow the firm’s partners to access the particular service. This is made possible by standards which define how Web services are described, discovered, and invoked. This adherence to strict standards enables applications in one business to inter-operate easily with other businesses. In addition, it allows application interactions across disparate platforms and those running on legacy systems and thereby offers a company the capability of conducting business electronically with potential business partners in a multitude of ways at reasonable cost. It has to be acknowledged that Web Services technology is only one of several technologies that enable component-based distributed computing and support information system integration efforts, largely due to its universal nature and the broad support by major IT technologies. Other standards, such as WSFL (Web Services Flow Language) or BPEL4WS (Business Process Execution Language for Web Services), also play an important role, but are not necessarily required to consume or provide Web Services, and if the location of the Web Service is known even UDDI is not required. Those basic concept and scenarios mentioned above could also be referred to http://www.w3.org/2002/ws/. The emergence of Web services has created unprecedented opportunities for organizations to establish more agile and versatile collaborations with other organizations. Widely available and standardized Web services make it possible to realize cross-organizational collaboration. A typical SOA paradigm based on Web Service rationale could be illustrated by Fig.3, in which there are three fundamental roles: Service Provider, Service Requestor and Service Registry and 3 fundamental operations: Publish, Find and Bind. The service provider is responsible for creating a service description, publishing its service description to one or more service registries, and receiving Web service invocation messages from one or more service requestors. A service requestor is responsible for finding a service description published to one or more service registries and is responsible for using service descriptions to bind to or invoke Web services hosted by service providers. The service registry is responsible for advertising Web service descriptions published to it by service providers and for allowing service requestors to search the collection of service descriptions contained within the service registry. Once the service registry makes the match, the rest of the interaction is directly between the service requestor and the service provider for the Web service invocation (Graham, 2001) Please note that even grid service is often recruited in grid application and scientific workflow research domain, as it is essentially a special web service that provides a set of well-defined interfaces and that follows specific conventions, we do not distinguish a grid service and web service in this chapter. In Fig.3, since they are intended to be discovered and used by other applications across the Web, Web services need to be described and understood both in terms of functional capabilities and QoS’s properties. Therefore, a service is always specified by its function-attributes (i.e. a service’s function specification including inputs, outputs, preconditions and effects) and its non-function attributes (e.g. time, price, availability, et al, for evaluating a service’s execution). Generally, the service profile primarily describes a service’s function-attributes. In cross-domain grid service invocations, quality of a grid service (mainly specified by its non-function) is often evaluated in terms of common security semantics, distributed workflow and resource management, coordinated fail-over, problem determination services, and other metrics across a collection of resources with heterogeneous and often dynamic characteristics. In (Zeng, 2004), five generic quality criteria for elementary services are presented as follows: (1) Execution price. Given an operation op of a service s, the execution price qpr(s; op) is the fee that a service requester has to pay for invoking the operation op. (2) Execution duration. Given an operation op of a service s, the execution duration qdu(s; op) measures the expected delay in seconds between the moment when a request is sent and the moment when the results are received. (3) Reputation. The reputation
400
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 3. A typical SOA paradigm based on Web service
qrep(s) of a service s is a measure of its trustworthiness. It mainly depends on end user’s experiences of using the service s. Generally, different end users may have different opinions on the same service. (4) Successful execution rate. The successful execution rate qrat(s) of a service s is the probability that a request is correctly responded (i.e., the operation is completed and a message indicating that the execution has been successfully completed is received by service requestor) within the maximum expected time frame indicated in the Web service description. The successful execution rate (or success rate for short) is a measure related to hardware and/or software configuration of Web services and the network connections between the service requesters and providers, and (5) Availability. The availability qav(s) of a service s is the probability that the service is accessible.
A Temporal Model of Service-Driven Scientific Workflow Execution In this chapter, we mainly focus on discussing scientific workflow scheduling with time-related QoS evaluation in grid environment. More specifically, a temporal model for service-driven scientific workflow execution is presented in this Section, and its further applications are investigated in later sections. In (Cardoso, 2004), four distinct advantages are highlighted for organizations to characterize their workflow developments and executions based on QoS: 1.
2.
3.
QoS-based design: it allows organizations to translate their vision into their business processes more efficiently, since workflow can be designed according to QoS metrics. For e-commerce processes it is important to know the QoS an application will exhibit before making the service available to its customers. QoS-based selection and execution: it allows for the selection and execution of workflows based on their QoS, to better fulfill customer expectations. As workflow systems carry out more complex and mission-critical applications, QoS analysis serves to ensure that each application meets user requirements. QoS monitoring: it makes possible the monitoring of workflows based on QoS. Workflows must be rigorously and constantly monitored throughout their life cycles to assure compliance both with initial QoS requirements and targeted objectives. QoS monitoring allows adaptation strategies to be triggered when undesired metrics are identified or when threshold values are reached.
401
Scientific Workflow Scheduling with Time-Related QoS Evaluation
4.
QoS-based adaptation: it allows for the evaluation of alternative strategies when workflow adaptation becomes necessary. In order to complete a workflow according to initial QoS requirements, it is necessary to expect to adapt, re-plan, and reschedule a workflow in response to unexpected progress, delays, or technical conditions. When adaptation is necessary, a set of potential alternatives is generated, with the objective of changing a workflow as its QoS continues to meet initial requirements. For each alternative, prior to actually carrying out the adaptation in a running workflow, it is necessary to estimate its impact on the workflow QoS.
In a service-driven workflow system, time is one of the key parameter engaged in its QoS specification (Cardoso, 2004). Timing constraint is often associated with organizational rules, laws, commitment, technical demands, and so on. In (Zeng, 2004), two timing constraints are put forward related to activities, which are internal timing constraint and external timing constraint. They specified the internal timing constraint as the execution duration or executable time span; and specified the external timing constraints as the temporal dependency relations between different activities. On the assumption that given a workflow model, designers could assign execution duration and executable time span (during which an activity could be executed) to every individual activity based on their experience and expectation from the past execution, Li, et al (Zeng, 2004) defined the duration time accurately in their timing constraint model. In practice, we believe that it may be more reasonable to specify the duration time as a time span. For example, it may be more acceptable to specify the execution duration is 3 days to 5 days (ab. (3, 5)) than to specify the execution duration is 4 days, at the stage of system modeling. By extending the timing constraint definitions presented in (Zeng, 2004) with this idea, we put forward a general timing constraint model for service invocation engaged in cross-domain workflow execution. Facilitating temporal-dependency analysis, we believe that service invocation cost often consists of service producing cost and service delivering cost. Service producing process aims at producing concrete service content, it underlies later service delivering. As service producing process is often deployed for reifying required service item, its time-related QoS evaluation is often calculated based on internal temporal cost inside an organization. Compared to service producing cost, time-related QoS evaluation of service delivering cost is often calculated based on external temporal cost associated with service distributing process among service providers and service consumers, as well as administrative cost consumed in cross-organizational collaboration. Accordingly, cost evaluation of a service invocation would be calculated based on this two cost calculating. For example, a car part vendor or car part enterprise receives an order for some parts, the service process spans the time from receiving the order to delivering its products. It often contains two stages: the first stage focus on manufacturing the required parts associated with enterprise’s internal time elapsing; the second stage focuses on timely delivering the required parts associated with enterprise’s external time elapsing. The QoS is often related to both the time of service producing process and service delivering process. Here, the internal time is determined by service producing process and the external time is determined by service delivering process. The cost of service could be evaluated based on the time cost associated with these two stages, which is two side of time analysis upon a same service invocation. Please note that in some situations, there could be only service delivering process without service producing process in some situation. For example, the service provided by Urban Emergency Monitoring and Support Centre (EMSC) is often related to service delivering without service producing process in a concrete service invocation process. Here, the QoS is only related to the time of service delivering. Associated with service producing process and service delivering process, some typical service invo-
402
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 4. A temporal logic-based time model for steering service innovation
cating modes are discussed, here, for specifying their coordination. Fig.4 illustrates a typical coordination relation between a service provider and a service consumer. The temporal parameters as illustrated in Fig.4 are specified by Table1. According to the temporal-dependency relation among these parameters as listed in Table1, some typical service innovation styles are specified as follows. 1. 2. 3. 4.
If SP-End =SD-Start, we believe that the service delivering process is a strong service delivering style. If SP-End <SD-Start, we believe that the service delivering process is a weak service delivering style. If SC-Start =SD-End, we believe that the service consuming process is a strong service invocation style. If SC-Start < SD-End, we believe that the service consuming process is a weak service invocation style.
In practice, SC-Start is often determined firstly, which initiated the service invocation in a bottom-to-up way. More specifically, a service provider often schedules its service producing process and its services delivering process according to the deadline required by a service consumer. What a service requestor
Table 1. Specifications of temporal parameters indicated in Figure 4 Temporal Parameters
Specifications
SD-Start
The start time of service delivering process
SD-End
The end time of service delivering process The start time of service producing process
SP-Start SP-End
The end time of service producing process
SC-Start
The start time of service consuming process
SC-End
The end time of service consuming process
[T-SR]
The time point for firing the service producing process
403
Scientific Workflow Scheduling with Time-Related QoS Evaluation
cares about is the expected time to achieve its required item; while the service provider take care of the time of service producing and service delivering, respectively, based on certain service providing deadline. Here, if the time pair of [SP-Start, SP-End] is degraded into (0, 0), it is a special service paradigm without the process of service producing. For example, if the car part vendor or car part enterprise has the required parts in stock, the time of part producing is omitted and the service process is depended on the process of part delivering. If the service provider and service consumer as illustrated in Figure4 respectively stand for two workflow fragments, it indicates a typical service-driven cross-domain workflow execution with timerelated QoS evaluation. It is more suitable for specifying a service-driven scientific workflow execution in a grid environment. Furthermore, in Fig.4, the service definitions mainly consist of such foundational prescriptions as definitions of service function, QoS prescription, cost evaluation, serving relation definition, and other service item definitions. It prescribes the policies of how to organize the required web service into a service-based workflow system. It definitely satisfies the requirements of a scientific workflow execution on security issues in grid environment. For example, in grid environment, resource access and resource sharing is often invocated through granting license to certain resource user and then opens the resource access to valid consumer (Yan, 2007; Foster, 2001). According to the rationale of temporal logic and the scenario of service invocating mode as demonstrated by Fig.4, certain security policy could be easily embed into grid service invocation for a grid computing paradigm. In practice, certain security policies are often integrated into a grid service’s QoS evaluation, which provide different profiles of control flow and data flow specification. In the following section, we will take advantage of this temporal model to explore the scheduling application of cross-domain scientific workflow execution in grid environment.
APPLICATION CONTExT ANALYSES OF SCIENTIFIC WORKFLOW ExECUTION As mentioned in (Yu, J., & Buyya, R., 2005), cross-organizational collaboration engaged in a scientific workflow often aims at obtaining specific processing capabilities through spanning multiple administrative domains. Here, a domain-specific application engaged in scientific collaboration is often uniquely associated with a local workflow fragment deployed in a self-managing organization. In this paper, when a workflow fragment refuses to disclose some of its process details for privacy or security reasons, it would be treated as a private workflow fragment of a self-managing organization. For a private workflow fragment, the actions and resources hidden from a scientific workflow specification and execution would be treated as silent actions and silent resources. Compared with the silent actions and silent resource, a self-managing organization only exposes its publicly accessible port for its scientific collaboration. Therefore, a private goal-specific workflow fragment consists of a set of silent actions, silent resources and some publicly accessible ports. It is essentially a gray box embedded in a scientific workflow. In scientific workflow execution, it is wholly a functional unit for scientific collaboration, and is triggered by its publicly accessible port for certain computing goals. In this paper, a publicly accessible port would be treated as an interaction interface between a scientific workflow and a self-managing organization. Fig.5 demonstrates a scientific workflow and its application context associated with three selfmanaging organizations. In Fig.5, a scientific workflow consists of three tasks (i.e., Ti, Tj, and Tk) and three resources (i.e., Ri, Rj, and Rk). Ti, Tj, and Tk are respectively associated with three private work-
404
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 5. Global application context of a cross-organizational scientific workflow execution
flow fragments (i.e., Pri-WF1, Pri-WF2, and Pri-WF3) for achieving certain local computing goals. Pri-WF1, Pri-WF2, and Pri-WF3 are respectively deployed inside three self-managing organizations (i.e., SM-Org-1, SM-Org-2, and SM-Org-3). Obviously, this scientific workflow is typically deployed in a cross-organizational way. For a scientific workflow specification, it can not covers the silent actions and silent resources contained in private fragments, as they exclusively belong to self-managing organizations for certain privacy or security reasons. Fig.6 illustrates Pri-WF1, Pri-WF2, and Pri-WF3, and a global scientific workflow view by masking the silent actions and silent resources engaged in Pri-WF1, Pri-WF2, and Pri-WF3. From Fig.6, we could find that Pri-WF1, Pri-WF2, and Pri-WF3 are respectively enacted by different self-managing organizations in isolated environments. The scientific workflow only covers their publicly accessible ports. As a private workflow fragment often masks part of its own internal workflow specification and its scheduling specification from the scientific workflow, it is a challenging endeavor to coordinate the executions of a scientific workflow and a private workflow fragment at runtime for their scientific collaboration. It greatly depends on the collaborative execution specification. In view of this challenge, we will then discuss the temporal context of a scientific workflow for its runtime scheduling. As mentioned in (Rajpathak, 2006), “scheduling deals with the assignment of jobs and activities to resources and time ranges in accordance with relevant constraints and requirements.” For a scientific workflow, its scheduling application is always promoted in a top-down way. For example, the scheduling tools such as Petri Net, WF-net, or DAG (Zeng, 2004; Li, 2003;van der Aalst, 1998; Guan, 2006) are typical associated with a direction from source behaviors to sink behaviors. They are typical a downstream scheduling style for scheduling application. In this scheduling style, the start time of the source behaviors are determined in advance, then succeeding activities are scheduled according to certain workflow patterns (e.g., And-Split, Or-Split, And-Join, and Or-Join workflow pattern (van der Aalst, 2003), to name a few) and certain temporal-dependencies (e.g., Before, Meet, Overlap (Allen, 1983), etc). Its scheduling application is unfolded in the same direction with its practical execution direction. Here, we take advantage of a time axis t1 to indicate the scheduling application of a scientific workflow.
405
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 6. Three private workflow fragments and a scientific workflow view by masking its silent context
For a private workflow fragment associated with a scientific workflow, its scheduling application is different from the scientific workflow. As a private workflow fragment is always triggered by its publicly accessible port, although there are certain source behaviors and sink behaviors in its model and its later concrete execution, the concrete temporal parameters of its behaviors could not be scheduled independently. Its scheduling application is unfolded by two steps. At the first stage, according to its expected computing goal specified by a scientific collaboration, a private workflow fragment schedules its workflow model and execution in an isolated application environment. At this scheduling stage, we take no consideration of the temporal constraints of the publicly accessible ports specified by the scientific workflow scheduling specification. Here, we take advantage of a time axis t2 to indicate the scheduling application environment of a private workflow fragment. At the second stage, taking advantage of the temporal constraints of the publicly accessible port, the temporal distributions of the private workflow fragment indicated by time axis t2 are wholly mapped onto time axis t1 to keep the temporal consistency with its publicly accessible port. Through time mapping, we can guarantee the temporal consistency between executions of a private workflow fragment and a scientific workflow for their scientific collaboration. The first scheduling stage aims at specifying a private workflow fragment’s internal temporal dependencies among its silent behaviors and publicly accessible port without external temporal constraints. Its scheduling application is initiated from a certain source point. It is unfolded in the same direction with the workflow fragment’s execution in practice. The second scheduling stage aims at keeping the external temporal consistency with a scientific workflow execution for certain scientific collaboration through temporal transferring from time axis t1 to time axis t2. Its temporal calculating process is initiated by a publicly accessible port. It may be unfolded in a reversed direction compared with the workflow fragment’s execution in practice. It is a typical hierarchical scheduling process. For example, in Fig.5,
406
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 7. Typical temporal parameters and their distributions for scheduling a scientific workflow SWF
publicly accessible ports of Ri and Ti inside SM-Org-1 stand for a sink resource and a sink task of a private workflow fragment Pri-WF1. In this situation, the scheduling application of Pri-WF1 depends on the expected start time of the scientific workflow. As the scheduling application of Pri-WF1 is initiated by the scheduling result of the scientific workflow, their executions should be scheduled in an incorporated way. Please note that the temporal disciplines (e.g., weak service delivering style, strong service delivering style, weak service invocation style, and strong service invocation style) presented in section 3 could be incorporated into the application context of a cross-organizational scientific workflow execution. A concrete example of service delivering style would be demonstrated in our evaluation analysis presented in section 6.2. In the next section, we will focus on exploring a temporal reasoning rule which can coordinate cross-organizational executions of a scientific workflow.
A Temporal Reasoning Rule for Collaborative Scheduling Application of Scientific Workflow According to the temporal model as presented in Section3, a temporal reasoning rule would be investigated in this section for cross-domain scientific workflow scheduling application. Firstly, suppose that there is just one publicly accessible port contained in a private workflow fragment in a self-managing organization. More complex situations would be investigated at the end of this section. Definition1. For a scientific workflow SWF, its expected executable duration could be specified by a time period of [SWF-Estart, SWF-Eend], in which SWF-Estart and SWF-Eend respectively stand for SWF’s expected start time and expected end time. Definition2. Suppose that there is a private workflow fragment Pri-WFi associated with a scientific workflow SWF. It has a publicly accessible port Pi engaged in SWF’s execution. For Pi, its expected executable duration could be indicated by a time period of [Pri-WFi-Ep-start, Pri-WFi-Ep-end], in which Pri-WFi-Ep-start and Pri-WFi-Ep-end respectively stand for Pi’ expected start time and its expected end time. Here, SWF-Estart, SWF-Eend, Pri-WFi-Ep-start, and Pri-WFi-Ep-end are specified by SWF’s scheduling specification. Fig.7 indicates this unique scheduling process of SWF with a time axis t1. Please note that the temporal parameters indicated by time axis t1 are relative time rather than absolute time. In practice, Pri-WFi is uniquely associated with SWF’s execution through Pi, in which SWF plays as a service consumer and Pri-WFi plays as a service provider in their cross-domain scientific collaboration. In their service-driven scientific collaboration, as a service consumer, SWF should firstly specify
407
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 8. Typical temporal parameters and their distributions for scheduling a private workflow fragment Pri-WFi
its service requirement, in terms of what and when; then, as a service consumer, Pri-WFi is scheduled for providing the demanded service, in time, in terms of how and when. Concretely, Pri-WFi’s execution aims at providing the demanded service based on SWF’s specification in time. Once a service item is determined in terms of what, required silent resources and silent task enactments could be deployed by a self-managing organization for achieving the expected computing goal. It is associated with the first scheduling stage as mentioned in Section2. To provide the demanded service in time, Pri-WFi’s implementation should be scheduled in terms of when. It is associated with the second scheduling stage as mentioned in Section2. Generally, for a goal-driven workflow execution, if there is no external temporal dependency with other workflow executions, it could be scheduled based on its capacity and past experiences in a selfmanaging way with a special execution goal (Li, 2003). Definition3. For a private workflow fragment Pri-WFi that takes no external temporal dependency with other workflow executions, its expected executable duration could be specified by a time period of [Pri-WFi-Estart, Pri-WFi-Eend], in which Pri-WFi-Estart and Pri-WFi-Eend respectively stands for Pri-WFi’s expected start time and its expected end time. Fig.8 demonstrates this unique scheduling process of Pri-WFi specified by time axis t2. Similarly, the temporal parameters indicated by time axis t2 are also relative time rather than absolute time. As Pri-WFi is uniquely associated with SWF through Pi, there are certain temporal dependencies between Pri-WFi and SWF. To provide the required computing service in time, Pri-WFi should be active in a required duration based on their temporal dependencies. Pri-WFi’s start time should be deduced based on the temporal constraints of its publicly accessible port specified by SWF’s specification rather than determined independently. Here, suppose that associated with time axis t2, Pi’s expected start time and expected end time are respectively indicated by Pri-WFi-E’p-start and Pri-WFi-E’p-end. Here, Pri-WFiE’p-start and Pri-WFi-E’p-end should be respectively equal to Pri-WFi-Ep-start and Pri-WFi-Ep-end in terms of absolute time or in execution. To keep the temporal consistency between Pri-WFi and SWF, the time parameters Pri-WFi-Estart, Pri-WFi-Eend, Pri-WFi-E’p-start and Pri-WFi-E’p-end indicated by t2 should be mapped to SWF’s time axis t1. In view of this observation, a temporal transferring rule will be investigated in this section, for keeping temporal consistency in cross-organizational scientific collaboration.
408
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 9. Temporal parameters and their distributions of a scientific workflow example SWF associated with time axis t1
1.
2.
For a scientific workflow SWF, as the time period of [SWF-Estart, SWF-Eend] covers the time period of [Pri-WFi-Ep-start, Pri-WFi-Ep-end], i.e., [Pri-WFi-Ep-start, Pri-WFi-Ep-end]⊆[SWF-Estart, SWF-Eend], SWFEstart should be determined firstly, then Pri-WFi-Ep-start and Pri-WFi-Ep-end are determined according to the values of SWF-Estart and SWF’s internal temporal distributions. This temporal scheduling is formalized by a scheduling logic of SWF-Estart [Pri-WFi-Ep-start, Pri-WFi-Ep-end]. It indicates a top-down or a global-to-local temporal reasoning path for scheduling a scientific workflow. For a private workflow fragment Pri-WFi, although the time period of [Pri-WFi-Estart, Pri-WFi-Eend] covers the time period of [Pri-WFi-E’p-start, Pri-WFi-E’p-end], i.e., [Pri-WFi-E’p-start, Pri-WFi-E’p-end]⊆[PriWFi-Estart, Pri-WFi-Eend], a different temporal scheduling logic is held. More specifically, only after the values of Pri-WFi-E’p-start and Pri-WFi-E’p-end are achieved based on the scheduling logic of SWFEstart [Pri-WFi-Ep-start, Pri-WFi-Ep-end], Pri-WFi-Estart and Pri-WFi-Eend could be deduced based on the concrete values of Pri-WFi-E’p-start, Pri-WFi-E’p-end and Pri-WFi’ internal temporal distributions. Here, Fig.8 illustrates Pri-WFi’s internal temporal distributions in a qualitative way. This temporal scheduling process could be formalized by a scheduling logic of [Pri-WFi-E’p-start, Pri-WFi-E’p-end] [Pri-WF -E , Pri-WF -E ]. It indicates a bottom-up or a local-to-global temporal reasoning i start i end path for scheduling a private workflow fragment in an incorporated scheduling environment. It is different from the global-to-local temporal reasoning path.
Pri-WFi-E’p-start and Pri-WFi-E’p-end should be respectively equal to Pri-WFi-Ep-start and Pri-WFi-Ep-end in terms of absolute time. Accordingly, the temporal association relation between SWF and WFi is specified by Definition4. Definition 4. The temporal dependency around a publicly accessible port between SWF and Pri-WFi could be formalized by [SWF-Estart, SWF-Eend] [Pri-WFi-Ep-start, Pri-WFi-Ep-end] [Pri-WFi-Estart, Pri-WFi-Eend] for keeping temporal consistency in cross-organizational scientific collaboration. Here, an example is presented to demonstrate the application of the temporal transferring process according to Definition 4. Fig.9 and Fig.10 respectively illustrate the scheduled temporal distributions a SWF and a Pri-WFi. These two scheduled temporal distributions are respectively associated with time axes t1 and t2. More specifically, in Fig.5, SWF-Estart=0, SWF-Eend=10, Pri-WFi-Ep-start=3, and Pri-WFi-Ep-end=5; in Fig.6, PriWFi-Estart=0, Pri-WFi-Eend=5, Pri-WFi-E’p-start=2, and Pri-WFi-E’p-end = 4. Here, a temporal association relation is taken into consideration between this two time axes. The incorporated temporal scheduling environment should be specified by a united time axis. For brevity and without the loss of generality, the time axis t1 would be selected as a united time axis of t. Here, some duration parameters associated with Pri-WFi are specified, as below, for later temporal reasoning.
409
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 10. Temporal parameters and their distributions of a private workflow fragment example PriWFi associated with time axis t2
1. 2. 3.
The duration between Pri-WFi-Estart and Pri-WFi-E’p-start is 2 time units, i.e., Pri-WFi-d1= 2 time units; The duration between Pri-WFi-E’p-start and Pri-WFi-E’p-end is 2 time units, i.e., Pri-WFi-d2= 2 time units, and, The duration between Pri-WFi-E’p-end and Pri-WFi-Eend is 1 time units, i.e., Pri-WFi-d3= 1 time units.
According to these parameters, the time parameters of Pri-WFi could be re-specified, as below, in the united time axis t. Fig.11 illustrates the re-specified temporal parameters and their distributions in the united time axis t. 1. 2. 3. 4.
Pri-WFi-E’p-start = Pri-WFi-Ep-start = 3. Pri-WFi-E’p-end = Pri-WFi-Ep-end = 5. Pri-WFi-Estart = Pri-WFi-Ep-start − Pri-WFi-d1 = 3 – 2 = 1. Pri-WFi-Eend = Pri-WFi-Ep-end +Pri-WFi-d3 = 5 + 1 = 6.
In Fig.11, Pri-WFi’s start time (i.e., Pri-WFi-Estart = 1) as specified by time axis t is an ideal start time for producing the required service item for SWF’s execution. Otherwise, Pri-WFi will occupy some additional time costs or can not provide the demanded service item in time. For example, if Pri-WFi starts at the zero time point in time axis t, i.e., Pri-WFi-Estart =0, as Pi’ expected start time is fixed in SWF’s specification, i.e., Pri-WFi-Ep-start = 3, and Pri-WFi-Ep-end = 5 could not be changed, the duration between Pri-WFi-Estart and Pri-WFi-Ep-start is 3 time units, i.e., Pri-WFi-d1= 3 time units. Obviously, it wastes 1 time unit compared to Tj-d1’s original value (i.e., Tj-d1=2) that we calculated previously. On the other hand, if Pri-WFi starts at the 2nd time point in time axis t, i.e., Pri-WFi-Estart =2, as the duration from Pri-WFiEstart to Pri-WFi-Ep-start is a fixed value, according to their relative time distributions, Pri-WFi-Ep-start should be at the 4th time point, i.e., Pri-WFi-Ep-start =4, to meet Pri-WFi’s workflow specification. Obviously, it Figure 11. Re-specified temporal parameters and their distributions of example SWF and Pri-WFi associated with a united time axis t based on their temporal dependent relation
410
Scientific Workflow Scheduling with Time-Related QoS Evaluation
delays the service invocation for satisfying Pri-WF’s execution. This example demonstrates a real-time application for scientific collaboration. In practice, the execution of a scientific workflow system may be a mixture of hard real-time applications and soft real-time applications. Generally, a system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed (Liu, 2002). Moreover, in a hard or immediate real-time system, the completion of an operation after its deadline is considered useless. On the other hand, a soft real-time system will tolerate such lateness and take the overhead of context switching into consideration. Soft real-time systems are typically useful if there are some issues of concurrent access that need to keep a number of connected systems up to date with changing situations. To incorporate the soft real-time property into workflow scheduling application, a publicly accessible port should have some typical attributes of Has-Earliest-Start-Time, Has-Latest-Start-Time, Has-Earliest-End-Time, and Has-Latest-End-Time as specified in (Rajpathak, 2006). Moreover, a temporal-dependable service initiated by a publicly accessible port subscribes to Allen’s (Allen, 1983) representation of standard time and relations between a private workflow fragment and a scientific workflow. These temporal attributes are key temporal constraints for task enactment and resource allocation for scientific collaboration. Here, some more complex situations would be investigated. Suppose that there is more than one publicly accessible port contained in a self-managing organization. With this scenario in our mind, some complex situations are distinguished as below. 1.
2.
3.
4.
If the ports belong to a same private workflow fragment Pri-WFi, and Pri-WFi just engaged in a scientific collaboration with a scientific workflow, its local temporal scheduling among its silent actions, silent resources and publicly accessible ports just aims at providing the demanded service item in time. In this situation, there is no conflict in resource sharing and task enactment, and it is easy to schedule a Pri-WFi in a self-managing way. If the ports belong to a same private workflow fragment Pri-WFi, and Pri-WFi is engaged in more than one scientific workflow in a concurrent environment, its local temporal scheduling among its silent actions, silent resources and publicly accessible ports should be coordinated with each other for satisfying different service items for different scientific workflows. It is required that Pri-WFi should compromise the service producing processes if there is a conflict in resource sharing and task enactment. If the ports belong to different private workflow fragments, and there is no shared silent action or silent resource for producing the service items among the private workflow fragments, the private workflow fragments could be scheduled independently with each other, according to the temporal transferring rule proposed in this paper. If the ports belong to different private workflow fragments but there are some shared silent actions or silent resources among the workflow fragments, the scheduling application of the workflow fragments should be promoted in an incorporated way. In the following section, an evaluation would be presented to demonstrate this complex situation based on the method presented in this section.
411
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 12. Scientific workflow execution process based on context switching and role binding
EVALUATION: A SCIENTIFIC WORKFLOW ENGINEERING DEVELOPMENT WITH TIME-RELATED qOS EVALUATION Fig.12 demonstrates a scientific workflow execution process based on context-awareness technique in a simulating way. It is a typically scheduler-based paradigm, and provides the foundation for development a context- and role-driven workflow engine through timely role binding. It is navigated through effectively context switching at runtime. More specifically, a Member judges its application situation, apperceives application context information for its behavior goals, selects a suitable role according to certain application logics, and then enters into a concrete application context with the role specification. The taxonomy of context as illustrated in Fig.12 navigates effective context-awareness and suitable role binding for promoting a scientific workflow execution. Please note that the application logic demonstrated in Fig.12 is spread from two directions with certain state transitions. One is initiated by a vertical navigating logic, and the other is horizontal navigating logic. The vertical navigating logic is initiated by three stages: task performing, resource accesses, and collaborating with others. The horizontal navigating logic is composed of context-awareness, runtime context switching, and concrete task execution. With this navigating discipline as demonstrated in Fig.12, cross-domain scientific workflow system could be effectively promoted in a collaborative way. Accordingly, a service-driven scientific workflow system can be characterized as sequences of service invocations based on certain temporal logic among distributed and heterogeneous stand-alone systems that can provide autonomous services. The autonomous services could be treated as task-oriented processing. According to the temporal disciplines presented in this chapter, a certificate-driven scientific workflow application paradigm will be explored with time-related QoS evaluation. In practice, a scientific workflow is often deployed in a cross-organizational way, which is often enabled in form of virtual organization. In (Foster, 2001), virtual organizations were characterized by flexible, secure, coordinated resource sharing among dynamic collections of individuals, institutions, and organizations. In (Yuan, 2000), three generic types of accounts on virtual organizations were sum-
412
Scientific Workflow Scheduling with Time-Related QoS Evaluation
marized. The first one is on organizations that extend some of their organizational activities externally, thus forming virtual alliances to achieve organizational objectives. Integrating several companies’ core competences and resources may form virtual organizations in a collaborative way. The second description of the virtual organization is related to a perceptual organization that is “abstract, unseeing and existing within the minds of those who form a particular organization”, which is an antithesis of the physical organization with which we are familiar. The third type of description is of organizations that are established with information technology such as corporations with an intensive use of telecommuting. Service execution times, level of control and flexible change control could be abstracted as key aspects for service-driven workflow specifications and enactment (Grefen, 1999), especially for processes crossing organizational boundaries (Grefen, 2001). For scientific workflow execution, servers supporting workflow application are decentralized (duplicated) throughout the virtual organization and the distributed servers are controlled by a centralized authority (headquarters). It is characterized by some basic features as follows. 1. 2. 3. 4. 5.
Lifetime of cooperative is limited; Organization-across collaboration; Access to a wide range of specialized resources during collaboration; Task- or goal-driven autonomous processes; Role-based communication, et ac.
Here, time constraints are often imposed on resource access or task enactment. At the stage of modeling an organization-across workflow, the concept of control flow is exploited to prescribe the service relation among organization with a temporal dependency. During workflow execution, control flow is instantiated into a logical switching according to a scheduled temporal logic among activities to satisfy certain collaboration. Temporal logic among cross-organizational collaboration often specifies the organization-across workflow execution for certain collaboration. If these temporal specifications are initiated by a global workflow engine, private workflow fragment in organization level could be automatically navigated with the specified temporal logic. It guarantees that these workflow fragments could be fired timely for satisfy certain collaboration in form of service invocation. Each workflow fragments in organization level could centralize on its inside-execution in self-governing way, taking little care of their temporal context switching. In Grid application environment, this temporal logic is often realized in form of certificate mechanism. Service is often opened by granting certificates to creditable candidates for their certain resource access. This certificate mechanism provides certain authorization in terms of what, when, who, and how, in which temporal discipline is a key factor for certificate granting and using. In view of these observations, a certificate-driven workflow execution scenario will be explored for cross-organizational workflow collaboration and resource access. The validity of certificate has a limited lifetime for their service invocation in workflow execution. This certificate-driven workflow execution scenario could be specified as follows: 1. 2.
Server-level or proxy-level private workflow fragments delegate their certificate granting to workflow engine; Invocation of services and functions among private workflow fragments are awakened through certificate granted by workflow engine;
413
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Figure 13. A grid-oriented and certificate-driven workflow system in self-governing fashion
3. 4.
The period of certificate’s validity reflects the lifetime of cooperative, and guarantees the QoS in time; Private workflow fragments are task- or goal-driven autonomous process, in which workflow engine play as a nerve center in a workflow system.
Essentially, this certificate-driven scientific workflow execution is initiated by a server-based workflow engine that control global workflow execution according to cross-organizational collaboration among private workflow fragments and their resource accesses. Fig.13 demonstrates the enactment of a prototype conformable to the service computing paradigm as demonstrated by Fig.1, Fig.2, and Fig.3. The collaboration disciplines engaged in Figure 13 are depicted as follows. Step1: Proxy-based private workflow fragment hand over their routines of certificate release to a global workflow engine that acts as the certificate authority in later scientific workflow executed. Step2: According to the pre-defined global scientific workflow application logic, the global workflow engine initiated cross-organizational collaboration through granting a certificate to a candidate for certain service innovation (resource access). Service invocation is enabled via a certificate identification and authentication, and validity of a certificate specifies the collaborative duration. Step3: After granting a certificate, a duplicated content of the certificate is sent to the resource or service host for identifying and authenticating future logging or visiting. Step4: According to the certificate and its security level, the certificate holder could get the access to the needed resource or invoke some service across the borders of different security domains in order to achieve its local computing goals. Step5: If a task is not finished in the period of validity, the resource access is forbidden. In this situation,
414
Scientific Workflow Scheduling with Time-Related QoS Evaluation
the actor must apply for an added time and then repeat step 2. Otherwise, the task is finished in the scheduled time. Please note that this step is indispensable, if there has an unexpected requirement during workflow execution across the borders of different security domains. The invocation processes among these steps are certificate-driven, which is essentially initiated by QoS evaluation. The granting is initiated by the temporal discipline discussed in the previous sections. The execution logic and the process logic are illustrated, respectively, by Fig.13.a and Fig.13.b. The period of validity is based on the time constraint model exploited in section 3. For achieving the object, the global scientific workflow engine demonstrated in Fig.13 should contain some basic items related to service definitions as below: 1. 2. 3. 4. 5.
Resource pool indexing the available resource supporting workflow execution Directory-based resource location mechanism and workflow-peer location mechanism A certificate authority (CA) for certificate granting Trigger mechanisms initiated by service invoking or ECA rules. Delegation capability supporting dynamic process data transportation, agent application, and other proxy-based issues in access control.
The scientific workflow engine is characterized by a key mechanism of service definition mentioned in section 3. Their temporal-dependent relation engaged in their cross-domain collaboration is navigated by the temporal-dependent rationale presented in section 4. Please note that the global scientific workflow engine plays as the part of a centrally managed security mechanism by taking over the security issue in certificate granting, while the issues or routines about authentication are carried out among private workflow fragment directly. Private workflow fragments have their security control inside themselves according to their service ability, storage space, security level, networking speed, and service demand in hierarchical way.
RELATED WORKS AND COMPARISON ANALYSIS The scheduling issue is very important for enhancing the scalability, autonomy, quality and performance of scientific workflows (Ludäscher, 2005; Yan, 2007; Li, 2006; Rajpathak, 2006). In (Yu, J., & Buyya, R., 2005), three major categories of scientific workflow scheduling architecture are presented, i.e., centralized, hierarchical and decentralized scheduling schemes. In the centralized workflow enactment environment, one central scheduler makes scheduling decision for all tasks engaged in future workflow execution. For hierarchical scheduling, there is a central manager and multiple lower-level sub-workflow schedulers. This central manager is responsible for controlling workflow execution and assigning sub-workflows to the lower-level schedulers. In contrast with the centralized and hierarchical schemes, there are multiple schedulers without any central controller in decentralized scheduling. A scheduler can communicates with others and schedules a sub-workflow to other schedulers with lower load. The authors (Yu, J., & Buyya, R., 2005) believed that the centralized scheme can produce efficient schedules because it has all necessary information about all tasks engaged in workflow execution. However, it is not scalable with respect to the number of task and Grid resource that are generally autonomous. The major advantage of using the hierarchical architecture is that different scheduling policies can be deployed in the central
415
Scientific Workflow Scheduling with Time-Related QoS Evaluation
manager and lower-level schedulers. However, the failure of the central manager will result in entire system failure. Decentralized scheduling is more scalable but faces more challenges to generate optimal solutions for overall workflow performance. The method presented in this paper falls into the third scheme, i.e., decentralized scheduling scheme. Compared with the related works, the main contributions of this paper are twofold. First, as a typical application environment, Grid is an efficient infrastructure for scientific workflow development and execution. In a general Grid environment, scheduling of resource allocation is an important issue for cross-organizational Grid service invocation based on certain privacy and security usage policies (Dumitrescu, 2005; Batista, 2008; Abramsona, 2002; Elmroth, 2008; Li, 2006). Generally, it takes less consideration of task scheduling application (i.e., private workflow fragment scheduling) enacted inside a self-managing organization for achieving a Grid service. In this paper, we incorporated the resource and task into a private workflow fragment scheduling for satisfying a demanded service item with certain QoS evaluation. It enhances the QoS of a cross-organizational service invocation for a scientific collaboration, through keeping the temporal consistency between a scientific workflow and the private workflow fragments. Second, for a cross-organizational scientific collaboration, privacy and security issues are key factors that should be incorporated into concrete scheduling application. In technique, brokering strategy (Abramsona, 2002; Elmroth, 2008) or view techniques (Chiu, 2004) have been proved as efficient approaches for dealing with this problem. In this paper, the collaboration scheduling is essentially promoted based on workflow view technique, in which publicly accessible ports play as interaction view opening for scientific workflow execution. Concretely, a scientific workflow imposes certain temporal constraints on the publicly accessible ports. The silent resources and the silent tasks engaged in a private workflow fragment are scheduled based on these temporal constraints of the publicly accessible ports. It guarantees that the scheduling application of a private workflow fragment is closely navigated by a scientific workflow scheduling application. To our best knowledge, the workflow view technique is mainly employed in cross-organizational business workflow for execution supervision. In this paper, we use this technique for collaboration scheduling of a scientific workflow, which is a novel application of workflow view technique.
CONCLUSION In this paper, a collaborative scheduling approach with time-related QoS evaluation is presented based on a temporal model. The proposed approach aims at keeping the temporal consistency of a scientific collaboration among distributed private workflow fragment in resource sharing and task enactments. Through an evaluation, we also demonstrated the capability of our approach for promoting multiple scientific workflow executions in a concurrent environment. This collaborative scheduling approach could also be helpful with QoS-aware middleware development for cross-organizational scientific collaborations, which will be studied as a future research topic.
416
Scientific Workflow Scheduling with Time-Related QoS Evaluation
ACKNOWLEDGMENT This paper is partly supported by the National Science Foundation of China under Grant No.60673017, and part of this chapter is cited from our previous research work.
REFERENCES Abramson, D., Buyya, R., & Giddy, J. (2002). A computational economy for grid computing and its implementation in the nimrod-g resource broker. Future Generation Computer Systems, 18(8), 1061–1074. doi:10.1016/S0167-739X(02)00085-7 Allen, J. F. (1983). Maintaining knowledge about temporal internals. Communications of the ACM, 26(11), 832–834. doi:10.1145/182.358434 Batista, D. M., da Fonseca, N. L. S., Miyazawa, F. K., & Granelli, F. (2008). Self-adjustment of resource allocation for grid applications. Computer Networks: The International Journal of Computer and Telecommunications Networking, 52(8), 1762–1781. Bowers, S., McPhillips, T. M., & Ludäscher, B. (2008). Provenance in collection-oriented scientific workflows. Concurrency and Computation, 20(5), 519–529. doi:10.1002/cpe.1226 Cardoso, J., Miller, J., Sheth, A., & Arnold, J. (2004). Quality of service for workflow and web service processes. Web Semantics: Science . Services and Agents on the World Wide Web, 1(3), 281–308. doi:10.1016/j.websem.2004.03.001 Chiu, D. K. W., Cheung, S. C., Till, S., Karlapalem, K., Li, Q., & Kafeza, E. (2004). Workflow viewdriven cross-organizational interoperability in a web service environment. Information Technology and Management, 5(3/4), 221–250. doi:10.1023/B:ITEM.0000031580.57966.d4 Dumitrescu, C. L., Wilde, M., & Foster, I. (2005). A model for usage policy-based resource allocation in grids. In R. Dienstbier (Ed.), Proc. 6th IEEE Int’l Workshop Policies for Distributed Systems and Networks (pp. 191-200). Stockholm, Sweden: IEEE Computer Society Press. Elmroth, E., & Tordsson, J. (2008). Grid resource brokering algorithms enabling advance reservations and resource selection based on performance predictions. Future Generation Computer Systems, 24(6), 585–593. doi:10.1016/j.future.2007.06.001 Foster, I., Kesselman, C., & Tuecke, S. (2001). The anatomy of the grid: Enabling scalable virtual organizations. The International Journal of Supercomputer Applications, 15(3), 200–222. Fox, G. C., & Gannon, D. (2006). Special issue: Workflow in grid systems. Concurrency and Computation, 18(10), 1009–1019. doi:10.1002/cpe.1019 Graham, S., Davis, D., Simeonov, S., Daniels, G., Brittenham, P., Nakamura, Y., et al. (Eds.). (2001). Building web services with Java™: Making sense of XML, SOAP, WSDL, and UDDI. New York: Sams Publishing.
417
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Grefen, P., Aberer, K., Ludwig, H., & Hoffner, Y. (2001). CrossFlow: Cross-organizational workflow management for service outsourcing in dynamic virtual enterprises. A Quarterly Bulletin of the Computer Society of the IEEE Technical Committee on Data Engineering, 24(1), 52–57. Grefen, P., & Hoffner, Y. (1999). CrossFlow: Cross-organizational workflow support for virtual organizations. Research Issues on Data Engineering: Information Technology for Virtual Enterprises(RIDE-VE ‘99.)(pp. 90-91). Sydney, Australia: IEEE Computer Society Press. Guan, Z., Hernandez, F., Bangalore, P., Gray, J., Skjellum, A., Velusamy, V., & Liu, Y. (2006). GridFlow: A grid-enabled scientific workflow system with a Petri-Net-based interface. Concurrency and Computation, 18(10), 1115–1140. doi:10.1002/cpe.988 Li, C., & Li, L. (2006). A sistributed multiple simensional QoS constrained resource scheduling optimization policy in computational grid. Journal of Computer and System Sciences, 72(4), 706–726. doi:10.1016/j.jcss.2006.01.003 Li, J. Q., Fan, Y. S., & Zhou, M. C. (2003). Timing constraint workflow nets for workflow analysis. [Part A]. IEEE Transactions on Systems, Man, and Cybernetics, 33(2), 179–193. doi:10.1109/ TSMCA.2003.811771 Liu, D. T., Franklin, M. J., Abdulla, G. M., Garlick, J., & Miller, M. (2006). Data-preservation in scientific workflow middleware. In R. Dienstbier (Ed.), Proc. 18th Int’l Conf. Scientific and Statistical Database Management (SSDBM’06)(pp. 49-58). Vienna, Austria: IEEE Computer Society Press. Liu, J. W. S. (Ed.). (2002). Real-times Systems. New York: Pearson Education Press. Ludäscher, B., & Goble, C. (2005). Guest Editors’ Introduction to the Special Section on Scientific Workflows. SIGMOD Record, 34(3), 3–4. doi:10.1145/1084805.1084807 McPhillips, T. M., & Bowers, S. (2005). An Approach for Pipelining Nested Collections in Scientific Workflows. SIGMOD Record, 34(3), 12–17. doi:10.1145/1084805.1084809 Rajpathak, D., Motta, E., Zdrahal, Z., & Roy, R. (2006). A Generic Library of Problem Solving Methods for Scheduling Applications. IEEE Transactions on Knowledge and Data Engineering, 18(6), 815–828. doi:10.1109/TKDE.2006.85 Rygg, A., Roe, P., Wong, O., & Sumitomo, J. (2008). GPFlow: An Intuitive Environment for Web-Based Scientific Workflow. Concurrency and Computation, 20(4), 393–408. doi:10.1002/cpe.1216 van der Aalst, W. M. P. (1998). The Application of Petri Nets to Workflow Management. J. Circuits . Syst. Comput., 8(1), 21–66. van der Aalst, W. M. P., Hofstede, A.H.M.ter, & Barros, A. P. (2003). Workflow Patterns. Distributed and Parallel Databases, 14(1), 5–51. doi:10.1023/A:1022883727209 Wieczorek, M., Prodan, R., & Fahringer, T. (2005). Scheduling of Scientific Workflows in the ASKALON Grid Environment. SIGMOD Record, 34(3), 56–62. doi:10.1145/1084805.1084816
418
Scientific Workflow Scheduling with Time-Related QoS Evaluation
Yan, Y., & Chapman, B. (2007). Scientific Workflow Scheduling in Computational Grids – Planning, Reservation, and Data/Network-Awareness. In R. Dienstbier (Ed.), Proc. 8th IEEE/ACM Int’l Conf. Grid Computing (pp. 18-25). Austin, Texas: IEEE Computer Society Press. Yu, J., & Buyya, R. (2005). A Taxonomy of Scientific Workflow Systems for Grid Computing. SIGMOD Record, 34(3), 44–49. doi:10.1145/1084805.1084814 Yu, J., Buyya, R., & Tham, C. K. (2005). Cost-based Scheduling of Scientific Workflow Applications on Utility Grids. In R. Dienstbier (Ed.), Proc. 1st Int’l Conf. e-Science and Grid Computing (e-Science’05) (pp. 1-8). Melbourne, Australia: IEEE Computer Society Press. Yuan, P. S., Matthew, K. O., & Shao, Y. L. (2000). Virtual Organizations: The Key Dimensions. In R. Dienstbier (Ed.), Proceeding of Academia/Industry Working Conference on Research Challenges (AIWORC’00) (pp. 3-8). Buffalo, New York: IEEE Computer Society Press. Zeng, L., Benatallah, B., Ngu, A. H. H., Dumas, M., Kalagnanam, J., & Chang, H. (2004). QoS-Aware Middleware for Web Services Composition. IEEE Transactions on Software Engineering, 30(5), 311–327. doi:10.1109/TSE.2004.11 Zhao, Z., Booms, S., Belloum, A., de Laat, C., & Hertzberger, B. (2006). VLE-WFBus: A Scientific Workflow Bus for Multi e-Science Domains. In R. Dienstbier (Ed.), Proc. 2th IEEE Int. Conf. e-Science and Grid Computing(e-Science’06)(p. 11). Amsterdam, Netherlands: IEEE Computer Society Press.
KEY TERMS AND DEFINITIONS Certificate Mechanism: A security policy recruited by Grid application, in which cross-domain resource sharing is enabled by certain certificate verification process among collaborators. Grid: Grid specifies the next generation infrastructure of Internet and its web-based applications. QoS: A set of evaluation parameters for evaluating the quality of a service. Scheduling: Scheduling deals with the assignment of jobs and activities to resources and time ranges in accordance with relevant constraints and requirements. Scientific Workflow: A novel workflow application style for e-Scientific activities. Temporal Model: A model for specify the temporal-dependent relation among collaborative activities. Workflow Fragment: A local workflow execution situation.
419
Section 5
Service Computing
421
Chapter 19
Grid Transaction Management and Highly Reliable Grid Platform Feilong Tang Shanghai Jiao Tong University, China Minyi Guo Shanghai Jiao Tong University, China
ABSTRACT As Grid technology is expanding from scientific computing to business applications, open grid platform increasingly needs the support of transaction services. This chapter proposes a grid transaction service (GridTS) and GridTS based transaction processing model, defines two kinds of grid transactions: atomic grid transaction for short-lived reliable applications and long-lived transaction for business processes. The chapter also presents solutions to managing these two kinds of transactions to reach different consistent requirements. Moreover, this chapter investigates a mechanism for automatic generation of compensating transactions in the execution of long-lived transactions through the GridTS. Finally, it discusses the future trends along the reliable grid platform research.
INTRODUCTION Grid computing is a natural evolution of distributed computing and Internet applications for largescale science and engineering problems, aiming at effective resource sharing and task collaboration in distributed and self-governing environments. The main goal of grid computing is sharing large-scale resources and accomplishing collaborative tasks through enabling people to utilize computing and storage resources transparently. By providing service oriented computing and data infrastructures, grid technology is becoming the preferred basis for large-scale distributed computing, and expanding from scientific computing to business applications (Berman,2003; Foster,2002; Wang, 2004). Many key grid applications especially business applications require reliability guarantee from highly reliable grid computing platform (Jiang 2006). As an effective and widely-used means, transaction DOI: 10.4018/978-1-60566-661-7.ch019
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Grid Transaction Management and Highly Reliable Grid Platform
technology can help people to make this vision a reality, providing application developers with multiple transparencies on location, replica, concurrency and failure (Wang, 2008). As a result, transaction management is one of the most important core services of reliable grid platform for the mission-critical commercial grid applications (Yang, 2008). In grids, a transaction is a set of operations that execute on geographically distributed grid services. Transaction management service is responsible for ensuring the reliable execution of these distributed grid applications to keep the system consistent, free the applications from various failures. Ideally, it also shields users from the complex recovery process. The traditional distributed transactions, where application systems are tightly coupled, have the ACID properties, i.e., Atomicity, Consistency, Isolation and Durability. However, traditional distributed transaction models and Web service transaction specifications do not work in open grid environments because: •
•
•
Grid systems are loosely coupled and autonomous. For the security and efficiency, autonomous grid services typically do not allow to be locked by outside applications while traditional atomic transaction models generally adopts locking mechanism to guarantee the atomicity. It is difficult even impracticable for application programmers to develop compensating transactions. Existing transaction models require application programmers to provide all compensating transactions. However, grid services that execute a business application are dynamically discovered; and autonomous service providers may set up special compensating rules based on their own business models. For example, some service providers allow users to cancel a ticket order without other actions while others may require users to pay some compensating fee. Grid systems are dynamic, i.e., grid services may exit the systems dynamically during an execution of a business process. Grid transaction service has to hide the dynamism from users.
As a result, it is a very important and significant work to propose and implement a transaction service for grid computing. Generally, a grid transaction service has to address following issues: • •
Coordination of the short-lived activities to form an atomic transaction, such as transferring fund from one bank account to another. Coordination of the long-lived transactional activities to fulfill a common agreement, for example, a journey arrangement that involves booking tickets, booking hotel rooms and hiring cars.
This chapter presents a grid transaction service (GridTS) and coordination algorithms to manage atomic and long-lived grid transactions, providing commercial applications with reliability support. Moreover, we propose a solution for automatic generation of compensating transaction, which is an significant advantage over existing long-lived transaction models. The objective is to set up a reliable grid platform based on transaction service for grid applications with reliable requirements, enabling application programmers to use the GridTS to implement transactional applications easily. The proposal has the following advantages over existing related researches. Firstly, the GridTS can automatically generate compensating transactions. Secondly, the GridTS can hide the dynamicity of grids from users. Next, the GridTS reserves resources for the atomic transaction commit to adapt to the autonomous grid environment. Finally, it is extensible because it is built on top of a series of open standards, technologies and infrastructures.
422
Grid Transaction Management and Highly Reliable Grid Platform
BACKGROUND The demands for reliable grid platform and transaction management service result from practical grid applications. Since the beginning of this century, both academia and computer industry have been regarding the development of grids as another chance to improve the current paradigm of Internet computing. ShanghaiGrid is a good example for such grid projects. As an internationalization city with 18 million people, Shanghai presents emergent needs for an information infrastructure to enable sharing of heterogeneous resources to improve government efficiency and quick response to emergent events. For sharing heterogeneous resources of computing, storage and data, Shanghai municipality launched the ShanghaiGrid project in 2003. ShanghaiGrid is a grid infrastructure that aggregates several heterogeneous supercomputers, data centers and other applications scattered in different organizations in Shanghai for city government as well as enterprises and communities. The primary goal is to establish a metropolitan-area service grid for widespread upper-layer applications from both research communities and government departments, tailored for the characteristics of Shanghai. The ShanghaiGrid project is built upon four major computational aggregations and networks in Shanghai, i.e., CHINANET (public Internet backbone built by China Telecom), SHERNET (Shanghai Education and Research Network), STNC (Shanghai Science and Technology Network Communication), and campus networks. From the perspective of hardware infrastructure, ShanghaiGrid aggregates various distributed and heterogeneous resources, including computers, networks, storage devices and so on. From the perspective of software infrastructure, one of the research focuses is to develop the ShanghaiGrid system software (SHGSS). The hardware facilities interconnected in ShanghaiGrid include supercomputers, data storages, devices (e.g., sensors and traffic surveillants) and other resources. These facilities are distributed in the intra-grids of the participating organizations of this project. As Figure 1 illustrates, the ShanghaiGrid hardware infrastructure comprises more than five connected intra-grids, including Shanghai Supercomputing Center (SSC) intra-grid, Shanghai Jiao Tong University (SJTU) intra-grid, Shanghai University (SHU) intra-grid, Tongji University (TJU) intra-grid and Shanghai Urban Traffic Information Center (SUTIC) intra-grid. The ShanghaiGrid system software SHGSS was designed with three levels: (1) the low-level access and management software for encapsulating heterogeneous resources as grid services, (2) the grid middleware that provide top-level traffic applications and others with transparent access to grid services, no matter where grid services are located, whether failures occur during execution of tasks, and how these services are composed, etc(Fox,2001), and the top-level grid portals that enable users to access ShanghaiGrid in a way similar to access Web. At the first stage, SHGSS supported resource encapsulation and management, service scheduling and accounting, data aggregation and adaptive transmission as well as an intelligent traffic management. After this stage, transaction management service was required for more key grid applications. From then on, grid transaction service was investigated and implemented. The following is researches and reports related to our grid transaction service. Transaction management for distributed environments have widely been researched (Ammann,1997; Ancilotti, 1990; Thomasian,1997). Traditional transaction models. Distributed Transaction Processing (DTP) and Object Transaction Service (OTS) are widely used in the traditional distributed environment. DTP defines three kinds of roles, Application Program, Transaction Manager and Resource Manager, and two types of interfaces, TX and XA interfaces. These two models do not release the locked resources until the end of a global
423
Grid Transaction Management and Highly Reliable Grid Platform
Figure 1. ShanghaiGrid hardware infrastructure
transaction, thus not able to coordinate long-lived grid transactions. Thus, they are generally not applicable for applications comprising loosely coupled, Web-based business services (Dalal,2003). Web Services transaction specifications. WS-Coordination (WS-C) and WS-Transaction (WS-T) provide a set of transaction specifications for Web Services (Cabrera,2002). WS-C describes a transaction framework comprising Activation Service, Registration Service and Protocol Service. It can accommodate multiple coordination protocols. WS-T classifies transactions in the Web Services environment into atomic transactions and business activities, and defines the corresponding coordination protocols. Business Transaction Protocol (BTP) is another important service-oriented transaction specification that defines a conceptional model and a set of complex messages to be exchanged between a coordinator and participants, specifies how to interact between Web services (Dalal, 2003). Compensating transactions. Existing long-lived transaction models were generally built on the conception of transaction compensation that was first proposed by Gray (Gray 1981). The typical implementation of compensating transactions is the Sagas model that is widely adopted in many extended transaction models (Chrysanthis,1992; Garcia-Molina,1987; Liang,1996). Sagas (Garcia-Molina,1987) is a classical transaction model for handling long-lived transactions, based on transaction compensation. In Sagas, a transaction is called a “Saga”, which consists of a set of sub-transactions with atomicity, consistency, isolation and durability properties such that T={T1, T2,…,Tn}, and a set of associated compensating transactions such that C={C1,C2,. . ., Cn}, where each sub-transaction Ti associates with a compensating transaction Ci that can semantically undo the effect caused by the commit of Ti. Sub-transactions in Sagas independently commit and immediately release
424
Grid Transaction Management and Highly Reliable Grid Platform
resources accessed in the execution of the sub-transactions in order to reduce the duration of resource lock and improve the system efficiency. In Sagas, all the committed sub-transactions must be undone if a subsequent sub-transaction fails, which causes waste of a lot of valuable work already finished. ACTA (Chrysanthis, 1992) is a comprehensive transaction framework that permits a transaction modeler to specify the effects of extended transactions on each other and on objects in the database. ACTA allows to specify interactions between transactions in terms of relationships and transactions’ effects on objects’ state and concurrency status. ACTA provides a reasoning ability more powerful and flexible than Sagas through a series of variations to the original Sagas. ConTracts (Wachter,1992) is a mechanism for grouping transactions into a multi-transaction activity. It consists of a set of predefined actions called steps, and an explicitly specified execution plan called a script. In case of a failure, the ConTract state must be restored and its execution may continue. The above transaction models do not work well in grid environments because 1. 2.
3.
Traditional atomic transaction models in general lock resources to achieve consistent commit. Grid services, however, are not ready to be locked by outside grid applications. Existing long-lived transaction models require application programmers to provide compensating transactions for all the sub-transactions. Business Transaction Protocol (BTP) and Web Services Transaction (WS-Transaction) also mentioned to use compensation for the coordination of longrunning activities, but they did not solve how to provide compensating transactions. Owing to the autonomy of grids, service providers may setup special compensating rules according their own business model, for example, different providers require users to pay different charges for the cancellation of ticket orders, while grid services that actually executes sub-transactions are dynamically discovered just before the beginning of a grid transaction. Application programmers do not know special compensating policies of services discovered dynamically, therefore are not able to provide corresponding compensating transactions in advance. Grid services may dynamically join and leave the grid system before a global grid transaction completes. The following will present how to extend related work for grid environments.
MAIN FOCUS OF THE CHAPTER Grid Transaction Service and Highly Reliable Grid Platform Grid transaction is a set of operations that execute on different grid services (Tang, 2004). The transaction service GridTS is a special service responsible for the coordination of these services to keep the system consistent, and shields users from the complex recovery process.
Layered Architecture The architecture of highly reliable grid platform consists of three layers (see Figure 2). The middle layer, GridTS, consists of following main components.
425
Grid Transaction Management and Highly Reliable Grid Platform
Figure 2. Architecture of reliable grid platform
Coordinator and Participant. They cooperatively coordinate a transaction for an application and grid services respectively. The Coordinator and Participant themselves do not execute actual application operations. Scheduler. This component takes charge of (1) creating a Coordinator and a coordination context (CC) on the application side and Participants on the service side, and (2) scheduling the Service Discovery module. Compensating Transaction Generator (CTG). If a predefined event occurs, the component first queries the corresponding compensating rule(s), and then dynamically generates a compensating operation. Also, it encapsulates the generated compensating operations into a compensating transaction when the sub-transaction commits. Log Service. This component records the coordination operations and the state information for recovery of transactions from failures. Service Discovery. This component dynamically discovers the qualified grid services according to users’ requirements, such as cost, quality and availability, to complete specified sub-transactions. Interfaces. GridTS provides grid applications with two types of APIs: the extended TX interfaces for transaction management, and the service-specific interfaces for management of the GridTS service instances and discovery of grid services to execute application operations in sub-transactions.
HOW TO USE GRIDTS GridTS is a special grid service so that it possesses all properties of a grid service. Interfaces of GridTS are encapsulated in TX portType of grid services by defining each interface, corresponding input and output parameters as operation, input and output messages. The interface definition is exemplified in Figure 3.
426
Grid Transaction Management and Highly Reliable Grid Platform
Figure 3. The definition of interface begin of GridTS
GridTS ensures the reliability for grid applications through the following ways. 1.
2.
Public transaction service. GridTS is published in the public registration center. Transactional applications discover and invoke the GridTS. The advantage in this way is flexible and convenient, which means that users may share reliability support without installing the GridTS. Private transaction service. The GridTS locates on the application-side and service-side nodes. The strength of this method is efficiency and the weakness is less flexibility.
Grid Transaction Processing Framework and Flow The framework of our grid transaction processing, shown in Figure 4, is built on GridTS, with the following three actors: 1.
2.
3.
Initiator. A transactional application is the initiator of a global grid transaction. It initiates the transaction through GridTS, then requests remote grid services involved in the transaction to execute application operations. GridTS. It is the grid transaction manager. Coordinator and Participant in the GridTS perform coordination algorithm according to the transaction kind. They interchange coordination messages to guarantee the consistency of global transaction. Coordinator is the controller of the global transaction. (Remote) Grid services. These gird services actually perform application operations in the transaction.
Based on above framework, a typical transaction processing flow is just like this. First, GridTS initiates a global transaction on behalf of an application, discovers and selects the required grid services to serve as participants. Then, its Scheduler broadcasts the CC messages to all selected participants. Finally, the created Coordinator and Participants interact to control the transaction execution, including correct completion and failure recovery. The following sections will discuss the details of transaction coordination.
427
Grid Transaction Management and Highly Reliable Grid Platform
Figure 4. GridTS-based transaction processing framework
TRANSACTION COORDINATION GridTS coordinated short-lived and long-lived transactions by executing the corresponding coordination algorithms based on the incoming transaction kinds.
Transaction Coordination for Atomic Grid Transaction Atomic transaction lasts a short time, typically within a few of seconds. The following is the formal definition.
Figure 5. An example of the atomic grid transaction
428
Grid Transaction Management and Highly Reliable Grid Platform
Figure 6. An example of transaction process: Dashed line refers to alternative candidate, which occurs only on the following long-lived transactions
Definition 1. An atomic transaction (AT) is a 4-tuple={T, D, S, R}, where T={T1, T2,. . ., Tn} is the set of atomic transactions, where Ti (1 ≤ i ≤ n) can be a set of lower-level atomic transaction Tij (1 ≤ j ≤ m) D is the set of data carried by the transaction, S is the set of states, and R is the set of dependency relationships between (sub)transactions. In an atomic transaction, all participants have to commit or abort synchronously, and the intermediate results of an atomic transaction are invisible (read or write) to other concurrent transactions. As shown in Figure 5, an atomic transaction that transfers 1000$ from an account in bank service A to another in bank service B such T={T1, T2}. The subtransaction T1 and T2 have to executed atomically. 1.
Coordination mechanism: Coordination of atomic grid transactions includes following phases: 1. Initiation of an atomic transaction. For remote grid service to join in an atomic transaction, the client-side GridTS sends CoordinationContext (CC) message to them and creates a Coordinator, which lives until end of the transaction. The CC message includes necessary information to create a transaction, including transaction type AT, transaction identifier, coordinator address and expiration. Participants return Response messages to Coordinator, indicating it agrees to join the transaction. 2. Preparation for the transaction commit. Coordinator sends Prepare messages to participants Pi (i=1, 2, . . ., N), where N is the number of subtransactions. Each Pi reserves necessary resources and returns Prepared or NotPrepared message, depending on whether the reservation is successful or not. 3. Transaction commit. Within T1, if Coordinator receives N Prepared messages, it sends Commit to all Pi and records the commit in log. Otherwise, it sends Abort to them, making them cancel the previous reservation. On receiving Commit message, each Participant: (a) requests for allocating the reserved resources, (b) records the transaction in log in order to recover later from possible failures, and (c) monitors the execution of corresponding task and report result to Coordinator.
429
Grid Transaction Management and Highly Reliable Grid Platform
Figure 7. Coordination algorithms of atomic transactions (CAAT)
2.
3.
430
Within T2, if Coordinator receives N Committed messages, it judges the transaction is correctly completed. Otherwise, it reports failure information to the user and sends Rollback messages to all Pi, making them recover to the previous states. In execution of a transaction, if any Pi itself contains sub-transactions, it will apply above mechanism recursively. In this case, nested transactions form a tree structure, and the Pi not only is a participant but also serves as the sub-coordinator for its children Pij (see Figure 6). Coordination Algorithm: The coordination algorithm of atomic transactions includes two parts: ActionOfParent and ActionOfChild, executed by the Coordinator and Participant respectively, as illustrated in Figure 7, where t is the waiting time of the Coordinator and the Participants, CC is the transaction context and Tc means the timeout that a Participant waits for the Commit message. Nested Atomic Grid Transactions: In the above coordination algorithm CAAT, if a participant nests lower-level sub-transactions it uses above mechanism recursively so as to form a transaction tree, where an internal node acts as not only a participant of its parent but also a sub-coordinator of its children, that is, these nodes interact with their parents in the participant algorithm and with their children in the coordinator algorithm. The root node represents a global transaction and it always executes the coordinator algorithm while leaf nodes actually perform application operations and always execute the participant algorithm. Formation of nested sub-transactions. Let P(i,j) is a Participant associated with the ith level and jth sub-transaction T(i,j) (j=1,2,. . ., n(i)), where n(i) is the number of sub-transactions in the ith level. We demonstrate the process for T(i,j) how to create its child transactions:
Grid Transaction Management and Highly Reliable Grid Platform
Figure 8. A long-lived transaction
1. 2. 3. 4.
T(i,j) calls interface Begin to initiate its child transactions and create a SubCoordinator(i,j). T(i,j) creates sub-transaction context CC(i+1, j) whose PortReference is the address of SubCoordinator(i,j), taking the current context CC(i,j) as the input parameter. T(i,j) propagates CC(i+1,j) to its all child transactions T(i+1,j’)(j’=1,2,. . ., n(i+1)). Each child transaction T(i+1,j’) creates a Sub-Participant(i+1,j’) and registers with the SubCoordinator(i,j) in a Response message. From then on, if T(i+1,j’) still nests child transactions, set i=i+1 and j=j’, CALGT repeats from above step 1 to 4 until it does not nest child transaction any longer.
Long-Lived Grid Transaction A long-lived transaction is the one that lasts for a long period such as a few hours even a few days because of the user interaction and processing delay. Long-lived transactions are generally associated with business processes so that they should have the following features. •
• •
It is convenient for a user to select committed sub-transactions in order to adapt to the business model. In view of cost or other factors, for example, a user often requests multiple services for the same subtask in a business process, then selects a “best” result, i.e., a traveler hopes to both buy the cheapest airline ticket and ensure his traveling plan uninterrupted so that he requests multiple booking services for only one airline ticket. Resources accessed by sub-transactions are released as early as possible to improve the system efficiency. Transaction service must provide the ability to shield the dynamicity of grids and make the global transaction proceed even if services involved in a transaction dynamically leave the grid system before the global transaction completes.
431
Grid Transaction Management and Highly Reliable Grid Platform
Definition 2. A long-lived grid transaction (LGT) is a 5-tuple={T,D,S,R,OP}, where T={Ti| Ti ∈T, 1≤i≤n, n is the number of sub-transactions involved in T} D is a set of data operated by T, S is a set of states, R is a set of dependency relationships between (sub)transactions, and OP={AP-OP, TM-OP} is a set of operations. TM-OP ⊆{Begin, Enroll, Confirm, Cancel} is a set of coordination messages and AP-OP is a set of application operations. For long-lived transactions, transaction compensation is an appropriate method to release grid resources being held by sub-transactions as early as possible. For example, in a traveling arrangement shown in Figure 8, a traveler orders airplane tickets from ticket service A and B, and reserves a room from service C. If the hotel reservation fails, the two ticket orders have to be cancelled. On the other hand, after the tickets are successfully booked, the traveler may select the “best” (e.g. the cheapest) one and cancels another. 1.
432
Coordination Mechanism: As the name suggests, a long-lived grid transaction LGT takes a relatively long time to finish, even without the interference from other concurrent transactions, so the LGT has to relax the atomicity and isolation properties. More specifically, a LGT allows some candidates to abort while others to commit. Application operations on grid services exhibit a loose unit of work where results are shared prior to completion of the global transaction, i.e, subtransactions in a LGT transaction independently commit, and then immediately release the held resources before the global transaction finishes. Compared with AT, LGT has following new characteristics: ◦ Grid services that participate in a transaction independently commit sub-transactions after receiving pre-commit message, then immediately release held resources. ◦ If some participants fail to participate in or commit a sub-transaction, a global transaction can proceed through initiating new requests to locate substitutes. ◦ Users can confirm or cancel committed sub-transactions according to their interests using compensating transactions. Note that a coordinator confirms or cancels each participant only once. ◦ Grid services that participate in a LGT may leave the grid before the global transaction completes. In that case, these services notify the coordinator before leaving the grid. Long-lived grid transaction processing consists of the following three phases: ◦ An application initiates a LGT transaction. It is similar to that in AT except the transaction type is LGT. ◦ Candidates commit independently. Coordinator sends Enroll messages to all candidates. The latter reserve and allocate necessary resources, record operations in log, then directly commit the transaction. If successfully, each candidate generates corresponding compensation transaction and returns Committed message, which contain execution results, to the Coordinator. Otherwise, it automatically rollbacks operations taken previously and returns Aborted messages. From then on, it is removed from the transaction. ◦ The user confirms successful candidates. According to the returned results, the user may take one of the following actions: (1) for candidates committing successfully, he confirms some and cancels the others by sending Confirm and Cancel messages to them respectively,
Grid Transaction Management and Highly Reliable Grid Platform
Figure 9. Coordination algorithms of long-lived grid transactions (CTLGT)
2.
3.
within Tvalid; and (2) for failed candidates, he needn’t reply them and may renew to send CoordinationContext messages to locate new candidates. As a result, if a candidate receives a Confirm message within Tvalid, it responds a Confirmed message. Otherwise, it executes a compensating transaction to recover the system to the previous state. Coordination algorithm: The coordination algorithm of LGT transactions (CALGT) also consists of two parts: the coordinator algorithm ActionOfCoordinator and the participant algorithm ActionOfParticipant, as shown in Figure 9, where t is the system time, CC is a coordination context, and Tvalid is the valid time within which a coordinator must send a confirmation or cancellation decision and participants must report their commit states. Otherwise, if a coordinator does not confirm or cancel a sub-transaction within Tvalid, the corresponding participant automatically undoes the committed sub-transaction by the compensating transaction. On the other hand, a coordinator presumes that a participant has failed if the participant does not return the commit result before Tvalid. The algorithm allows users to confirm or cancel committed sub-transactions according to their own requirements. In above long-lived coordination algorithm, if a sub-transaction Ti comprises lower-lever subtransaction Tij it calls coordinator algorithm in the nested way described in above Section. Shielding the Dynamicity of Grid Services: Services that participate in a LGT may exit from the grid before the global transaction completes. GridTS shields the dynamicity of grid in the following ways.
433
Grid Transaction Management and Highly Reliable Grid Platform
Figure 10. A LGT transaction and its compensating transactions
1.
2.
Keep on handling the global transaction. If a grid service leaves the grid before the global transaction completes, it notifies the coordinator of this decision by means of notification mechanism of grid. To support for subscription of notification message, the Coordinator implements NotificationSink interface to receive notification messages and the Participant implements NotificationSubscription and NotificationSource interfaces to manage subscription and send notification messages. Moreover, the CC message provides enough information to direct remote services how to notify the coordinator of their decision before they leave the grid system. The subscription request within the CC consists of: ▪ The kind and content of notification messages, ▪ The address to call NotificatonSink, i.e., the network address of the coordinator, and ▪ The initial lifetime of subscription, which is equal to Tvalid. When a service leaves the grid, the associated GridTS notifies the coordinator using the NotificatonSink. The coordinator resends CC message to new grid service to perform that sub-transaction, where the valid expiration of the new service is still Tvalid. Undo effects on grid services. Let services do not leave grid in the commit process. Services may leave grid in the following two situations and GridTS will take corresponding actions. 1. A grid service leaves grid before the commit of a sub-transaction. In this case, the service simply leaves grid without performing compensating actions. 2. A grid service leaves the grid after the commit of a sub-transaction, when its coordinator has received the Enrolled message. In this case, the coordinator sends Cancel messages to notify participants of execution of compensating transactions.
AUTOMATIC GENERATION OF COMPENSATING TRANSACTIONS Existing long-lived transactions models were generally built on compensating transactions, both in the traditional distributed systems and in the Web Services environments. The compensating transaction was first implemented in Sagas that requires application programmers to provide compensating transactions before a transaction execution. This section focuses on how to automate the generation of compensating transactions for grid environments, free application programmers from complex compensation details. We define the common compensating rules for data modification operations and transaction coordination messages, while
434
Grid Transaction Management and Highly Reliable Grid Platform
Figure 11. Generation of compensating transactions
allowing service providers to add and modify their own rules. In the execution of a LGT, the GridTS dynamically generates and stores a compensating transaction for each sub-transaction based on the compensating rules, shown in Figure 10. On receiving a Confirm message, the GridTS deletes the generated compensating transaction from the database because the result(s) of the sub-transaction will not change from then on.
Key Technologies for Automatic Generation of Compensating Transaction Compensating actions are closely related to system states. The states describe current properties and possible further action(s) of a transaction system. For example, we can describe the state of an airline booking system as S={reservation, available}, where reservation is the number of available tickets, and available indicates whether the system can accept new reservations or not. If reservation is greater than 0, available becomes true. Otherwise, available becomes false. States are changed by operations. However, not all operations affect system states. For example, the update(d1,d2) operation changes the data value from d1 to d2 and the Enroll message transfers the Participant state from Active to Committing, but reading a data value does not affect the system state. Definition 3. A compensating transaction (CT) is the transaction that rollbacks the operations taken by a committed transaction T and undoes semantically the effects from the commit of T, the original transaction of the compensating transaction. A compensating transaction mainly involves in two aspects. One is to undo the effects of the original operations, and another is to recover the system consistency. The key technologies to generate automatically compensating transactions include: • • •
Definition of compensating rules, Generation of compensating operations in the execution of a long-lived transaction, and Generation of a compensating transaction at the commit of a sub-transaction.
435
Grid Transaction Management and Highly Reliable Grid Platform
Set Compensating Rules Generation of a compensating transaction is event-driven. Compensating rules indicate how to undo the effects from events that change system states. We divide these events into three types: data modification event, transaction coordination event and service self-definition event (see Figure 11). Compensating rules for the first two types of events are provided by GridTS while rules for service self-definition events are set by service providers through the following interfaces: • •
setCompensatingRule (): sets compensating rules for grid services. getCompensatingRule (): gets compensating rules of grid services.
1.
Data modification event: Currently, most companies store their information in relation databases. Data modification operations in a LGT mainly consist of insertion, deletion and replacement of records in databases. Definition 4. A data modification event refers to insertion, deletion or modification of databases. Let eTi[p(d)] be a data modification event from which transaction Ti modifies data d using operation p, where p∈OT belongs to one of operation types. Furthermore, DETi is a set of data modification events caused by Ti and eTi[p(d)] ∈DETi. For a relation database, OT={update, insert, delete}. We mainly analyze how to compensate these three data modification operations. Let Si and Si+1 be the states before and after Ti commits respectively, CTi a compensating transaction of Ti, and Tj (j≠i) a dependent transaction that concurrently executes between Ti and CTi. If data accessed by Ti is not modified by Tj, CTi simply executes a reversed action for each operation in Ti. Otherwise, CTi undoes the committed transaction Ti, but may not change the results of the dependent transaction Tj . For example, the cancellation of Alice’s airline ticket reservation can not affect Bob’s reservation. Compensating rules for update, insert and delete operations are set as follows. Update: Let opi=update(d1,d2) be a operation in Ti that replaces d1 with d2. How to compensate opi depends on the data modification operation opj in Tj. An insert operation opj=insert(d) in Tj does not affect the result of opi. The compensating operation for opi is copi= update(d2,d1). A delete operation opj= delete(d2) in Tj will delete the result of opi. As a result, it is not necessary to compensate opi. An update operation opj =update(d2,d3) in Tj will change the result of opi. The compensating operation of opi depends on the type of the replacement operation. Relevant replacement Si+1 =f(Si, Ti). It means that the state Si+1 is relevant to the state Si. copi has to remove the effect of opi. For example, if opi=update(d1,d2) and d2=d1+n, the corresponding compensating operation is copi=update(d3,d4), where d4=d3-n. Irrelevant replacement Si+1=f(Ti), where Si+1 is irrelevant to Si, e.g., opi=update(“Monday”, “Tuesday”) and opj=update(“Tuesday”,“Wednesday”). Such a replacement need not be
436
Grid Transaction Management and Highly Reliable Grid Platform
2.
compensated. Insert: Let operation opi=insert(d1) in Ti insert a record with value d1. copi is also relevant to data modification operations opj in Tj . opj =insert(d2) does not affect the result of opi so that the compensating rule for opi is copi = delete(d1). opj =delete(d1) will delete the result of opi, however, opi need not be compensated in order to keep the result of opj. opj =update(d1, d2) shall be compensated as follows. If (d2≠d1) If (relevant replacement) { temp=change caused by opj=update(d1, d2); insert (temp); delete(d1); } else do nothing; Delete: A delete operation opi=delete(d) in Ti deletes a record with the value d. Any operation in Tj can not affect the result of opi so that the compensating operation for opi is simply a reversed operation copi =insert(d). Transaction Coordination Event: Definition 5. A transaction coordination event denotes that a sub-transaction receives messages from a coordinator. The set of transaction coordination events involved in a sub-transaction Ti is TETi ⊂{CC, Enroll, Confirm, Cancel}.
3.
Each transaction coordination event changes the state of a transaction system. The GridTS sets the compensating rules for the transaction coordination event in the following way. ◦ For CC message, it records the original transaction identifier and input parameters. ◦ For Enroll message, it encapsulates compensating operations in delimiters Begin and Commit, and stores the compensating transaction CTi in a database. ◦ For Cancel messages, it invokes CTi stored in the database. ◦ For Confirm message, it deletes CTi in the database because CTi will be useless after the subtransaction is confirmed. Service self-definition event: Definition 6. A service self-definition event refers to the actions that a service provider takes according to the states of a business process, which depends on the special business model of a service provider. The compensating rules for the service self-definition event are defined by service providers. They typically focus on: ◦ Subsequent activities after undoing operations in an original transaction, e.g., sending an email to notify the user of new available services.
437
Grid Transaction Management and Highly Reliable Grid Platform
◦
Economic compensation. For example, if a user cancels a committed sub-transaction which has finished a transportation order, the transportation company typically requires amends from the user.
Generate Compensating Operations In the execution of a LGT, the Compensating Transaction Generator (CTG) of GridTS monitors events, such as a delete operation or an Enroll message. Once predefined events occur, CTG examines whether the conditions for a rule are satisfied. If so, it extracts the type and parameters of the operation, queries corresponding compensating rules of the operation, generates a compensating operation, and records input parameters. For example, when a sub-transaction deletes a record from the database, the Delete event will generate a compensating operation to insert the record.
Generate and Call Compensating Transactions The Enroll message enables the CTG to generate delimiters Begin and Commit, and combines the compensating operations into a transaction. If the sub-transaction fails, all compensating operations generated previously are abandoned. A compensating transaction is stored in a database, and deleted from the database when GridTS receives a Confirm message from the Coordinator. In a LGT, both the Cancel message and a timeout signal, which is generated after the transaction expiration Tvalid, can start the corresponding compensating transaction.
Handle Noncompensable Transaction A transaction is compensable if effects from its commit can be semantically undone by another transaction, i.e., the corresponding compensating transaction. Otherwise, the transaction is noncompensable. A compensating transaction consists of a set of compensating operations. A transaction T is compensable, if and only if each operation OPi∈T has a corresponding compensating operation COPi. Some transactional grid applications comprise noncompensable operations so that these transactions are noncompensable. Generally, noncompensable operations can be divided into two types: 1. 2.
Difficult compensating operations such as the sale of stocks bought previously, which means that the execution of these compensating operations may cause unexpected results. Unable compensating operations, which refer to the operations that can not be compensated. For example, it is impossible to compensate a launched missile.
Noncompensable operations often generate effects on outside activities so that in general, their effects are not allowed visible out of these applications. Thus, GridTS does not allow such a sub-transaction to commit in the pre-commit phase if it can not find compensating rule(s) for an operation. Instead, we handle noncompensable transactions with the following policies. • •
438
GridTS imposes commit dependence between the sub-transaction and the global transaction, which indicates that the sub-transaction actually commits only if the global transaction commits. GridTS rollbacks operations taken previously but returns the Committed message to the coordinator.
Grid Transaction Management and Highly Reliable Grid Platform
•
After receiving the Confirm message, it redoes and commits the sub-transaction. GridTS rollbacks the executed operations and reports a commit exception to a user. The latter decides how to handle the exception.
FUTURE TRENDS We have proposed a transaction service GridTS and coordination algorithms for short-lived and longlived transaction management in grid environments. It is an effort towards the reliable grid platform. With the increasing reliability requirements from business applications, reliable grid platform will be an important research direction. Transaction service is an indispensable component for emerging reliable grid infrastructure. Therefore, our GridTS and coordination algorithms will provide the powerful support for research on reliability of grid platform. The future research along with this direction includesthe following aspects in order to make GridTS more practical and effective in the commercial grid environment. The first one is security guarantee during transaction processing. Grid Security Infrastructure (GSI) may be used because it provides the abilities for authentication, authorization and communication protection, based on the public-key mechanism, and is the de facto standard authentication method with “single sign-on” property. Another issue is to investigate the mechanism for solving the possible deadlock problem of competing transactions, as well as the approach for combining the transaction management with the resource scheduling and management to enhance system efficiency.
CONCLUSION We have proposed a grid transaction service GridTS and coordination algorithm for management of short-lived and long-lived reliable activities in grids. GridTS can coordinate different grid transactions through executing corresponding coordination algorithms. The design that separates GridTS and algorithms makes GridTS more flexible and scalable by means of adding new algorithms for coming reliable applications. Our proposal has three advantages. Firstly, for transactional grid applications, users only need to submit the corresponding parameters (e.g., the transaction type and timeout). GirdTS can intelligently invoke different coordination algorithms and handle the entire transaction process on behalf of the users. The complex process is hidden from the users. Secondly, GridTS is able to dynamically generate compensating transactions in the execution of long-live transactions, and at the same time provides interfaces for setting up service-specific compensating rules to satisfy different application requirements. Next, the long-lived coordination algorithm allows users to select committed results, which is applicable to practical business applications. Finally, GridTS is extensible because it is built on top of a series of open standards, technologies and infrastructures.
439
Grid Transaction Management and Highly Reliable Grid Platform
ACKNOWLEDGMENT Feilong Tang would like to thank The Japan Society for the Promotion of Science (JSPS) and The University of Aizu (UoA), Japan for providing the excellent research environment during his JSPS Postdoctoral Fellow Program in UoA, Japan. Thanks are also given to Dr. Chao-Li Wang in The University of Hong Kong, China and Professor Zixue Cheng in UoA, Japan for their precious helps. This work is supported by the National High Technology Research and Development Program (863 Program) of China (Grant Nos. 2006AA01Z172, 2006AA01Z199 and 2008AA01Z106), the National Natural Science Foundation of China (NSFC) (Grant Nos. 60773089,60533040, and 60725208), and Shanghai Pujiang Program (Grant No. 07pj14049).
REFERENCES Ammann, P., Jajodia, S., & Ray, I. (1997). Applying formal methods to semantic-based decomposition of transactions. [TODS]. ACM Transactions on Database Systems, 22(2), 215–254. doi:10.1145/249978.249981 Ancilotti, P., Lazzerini, B., & Prete, C. A. (1990). A distributed commit protocol for a multicomputer system. IEEE Transactions on Computers, 39(5), 718–724. doi:10.1109/12.53589 Berman, F., Fox, G., & Hey, T. (Eds.). (2003). Grid computing making the global infrastructure a reality. New York: Wiley Series in Communication Networking & Distributed Systems. Cabrera, F., Copel, G., & Coxetal, B. (2002). Web Services Transaction (WS- Transaction). Retrieved from http://www.ibm.com/developerworks/library/ws-transpec. Chrysanthis, P., & Ramamriham, K. (Eds.). (1992). ACTA: The SAGA continues. Transactions Models for Advanced Database Applications. San Francisco: Morgan Kaufmann. Chrysanthis, P. K., & Ramamriham, K. (1994). Synthesis of extended transaction models using ACTA. ACM Transactions on Database Systems, 19(3), 450–491. doi:10.1145/185827.185843 Dalal, S., Temel, S., & Little, M. (2003). Coordinating business transactions on the Web. IEEE Internet Computing, 7(1), 30–39. doi:10.1109/MIC.2003.1167337 Foster, I., Kesselman, C., & Nick, J. (2002). Grid services for distributed system integration. IEEE Computer, 35(6), 37–46. Fox, F., & Gannon, D. (2001). Computational grids. Computing in Science & Engineering, 3(4), 74–77. doi:10.1109/5992.931906 Garcia-Molina, H., & Salem, K. (1987). SAGAS. In Proceedings of ACM SIGMOD’87, International Conference on Management of Data, 16(3), 249-259. Gray, J. (1981). The transaction concept: Virtues and limitations. In Proceedings of the 7th International Conference on VLDB, (pp.144-154).
440
Grid Transaction Management and Highly Reliable Grid Platform
Jiang, J. L., Yang, G. W., & Shi, M. L. (2006). Transaction Model for Service Grid Environment and Implementation Considerations. In Proceedings of IEEE International Conference on Web Services (pp. 949 – 950). Liang, D., & Tripathi, S. (1996). Performance analysis of longlived transaction processing systems with rollbacks and aborts. IEEE Transactions on Knowledge and Data Engineering, 8(5), 802–815. doi:10.1109/69.542031 Tang, F. L., Li, M. L., & Huang, Z. X. (2004). Real-time transaction processing for autonomic Grid applications. Engineering Applications of Artificial Intelligence, 17(7), 799–807. doi:10.1016/S09521976(04)00122-8 Thomasian, A. (1997). A performance comparison of locking methods with limited wait depth. IEEE Transactions on Knowledge and Data Engineering, 9(3), 421–434. doi:10.1109/69.599931 Wachter, H., & Reuter, A. (Eds.). (1992). Contracts: A means for Extending Control Beyond Transaction Boundaries. Advanced Transaction Models for New Applications. San Francisco: Morgan Kaufmann. Wang, T., Vonk, J., Kratz, B., & Grefen, P. (2008). A survey on the history of transaction management: from flat to grid transactions. Distributed and Parallel Databases, 23(3), 235–270. doi:10.1007/s10619008-7028-1 Yang, Y. G., Jin, H., & Li, M. L. (2004). Grid computing in China. Journal of Grid Computing, 2(2), 193–206. doi:10.1007/s10723-004-4201-2 Yang, H. T., Wang, Z. H., & Deng, Q. H. (2008). Scheduling optimization in coupling independent services as a Grid transaction. Journal of Parallel and Distributed Computing, 68(6), 840–854. doi:10.1016/j. jpdc.2008.01.004
KEY TERMS AND DEFINITIONS Atomic Transaction: A short-lived transaction with the property “all or nothing”, i.e., subtransactions in an atomic transaction all commit or abort. Compensating Transaction: A transaction for undoing submitted transactions, which means canceling submitted operations and recovering system consistency. Grid Computing: A distributed computing paradigm for large-scale and effective resource sharing and task collaboration through enabling people to utilize computing and storage resources transparently. Grid Transaction: A set of operations that are execute on geographically distributed grid services Long-Lived Transaction: A transaction with a long lifetime. Generally, a long-lived transaction relaxes the atomicity and isolation properties. Reliability: In transaction processing, reliability is an ability of a system or component to keep system consistency through performing its required functions under stated conditions for a specified period of time. Transaction Processing: A technology responsible for ensuring the reliable execution of these distributed grid applications to keep the system consistent and free from various failures. Ideally, it also shields users from the complex recovery process.
441
442
Chapter 20
Error Recovery for SLABased Workflows Within the Business Grid Dang Minh Quan International University in Germany, Germany Jörn Altmann Seoul National University, South Korea Laurence T. Yang St. Francis Xavier University, Canada
ABSTRACT This chapter describes the error recovery mechanisms in the system handling the Grid-based workflow within the Service Level Agreement (SLA) context. It classifies the errors into two main categories. The first is the large-scale errors when one or several Grid sites are detached from the Grid system at a time. The second is the small-scale errors which may happen inside an RMS. For each type of error, the chapter introduces a recovery mechanism with the SLA context imposing the goal to the mechanisms. The authors believe that it is very useful to have an error recovery framework to avoid or eliminate the negative effects of the errors.
INTRODUCTION In the Grid Computing environment, many users need the results of their calculations within a specific period of time. Examples of those users are meteorologists running weather forecasting workflows, automobile producers running dynamic fluid simulation workflow (Lovas et al., 2004). Those users are willing to pay for getting their work completed on time. However, this requirement must be agreed on by both, the users and the Grid provider, before the application is executed. This agreement is kept in the Service Level Agreement (SLA) (Sahai et al., 2003). In general, SLAs are defined as an explicit statement of expectations and obligations in a business relationship between service providers and customers. DOI: 10.4018/978-1-60566-661-7.ch020
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Error Recovery for SLA-Based Workflows
SLAs specify the a-priori negotiated resource requirements, the quality of service (QoS), and costs. The application of such an SLA represents a legally binding contract. This is a mandatory prerequisite for the Next Generation Grids. The basic concepts of a system handling the Grid-based workflow within an SLA context are described in the following sections.
Grid-Based Workflow Model Workflows received enormous attention in the databases and information systems research and development commun