Grid computing : an introduction Lionel Brunie Institut National des Sciences Appliquées Laboratoire LIRIS – UMR CNRS 5205 – Equipe DRIM Lyon, France
A Brain is a Lot of Data! (Mark Ellisman, UCSD) And comparisons must be made among many We need to get to one micron to know location of every cell. We’re just now starting to get to 10 microns
Données intensives • Physique nucléaire et des hautes énergies • Simulations – Observation terrestre, modélisation du climat – Géophysique, modélisation des tremblements de Terre – Aérodynamique et dynamique des fluides – Dispersion de polluants • Astronomie : les futurs télescopes produiront plus de 10 Petaoctets par an ! • • Génomique Chimie et biochimie Applications financières Imagerie médicale
Evolution de la performance des composants informatiques • Performance Réseau/Processeur – La vitesse des processeurs double tous les 18 mois – La vitesse des réseaux double tous les 9 mois – La capacité de stockage des disques double tous les 12 mois • 1986 à 2000 – Processeurs : x 500 – Réseaux : x 340000 • 2001 à 2010 – Processeurs : x 60 – Réseaux : x 4000 Moore’s Law vs. storage improvements vs. optical improvements. Graph from Scientific American (Jan-2001) by Cleo Vilett, source Vined Khoslan, Kleiner, Caufield and Perkins.
Conclusion : invest in networks !
Hansel and Gretel are lost in the forest of definitions • • • Distributed system Parallel system Cluster computing Meta-computing Grid computing Peer to peer computing Global computing Internet computing Network computing Cloud computing
Distributed system • N autonomous computers (sites) : n administrators, n data/control flows • an interconnection network • User view : one single (virtual) system – «A distributed system is a collection of independent computers that appear to the users of the system as a single computer » Distributed Operating Systems, A. Tanenbaum, Prentice Hall, 1994 • « Traditional » programmer view : client-server
Parallel System • 1 computer, n nodes : one administrator, one scheduler, one power source • memory : it depends • Programmer view : one single machine executing parallel codes. Various programming models (message passing, distributed shared memory, data parallelism…)
Examples of parallel system Memory CPU CPU Interconnection network A CC-NUMA architecture CPU Memory network Memory CPU network Periph. network CPU Memory A shared nothing architecture CPU CPU
Cluster computing • Use of PCs interconnected by a (high performance) network as a parallel (cheap) machine • Two main approaches – dedicated network (based on a high performance network : Myrinet, SCI, Infiniband, Fiber Channel. . . ) – non-dedicated network (based on a (good) LAN)
Where are we today ? • A source for efficient and up-to-date information : www. top 500. org • The 500 best architectures ! • N° 1 : 1457 (1105) Tflops ! N° 500 : 22 (13) Tflops • Sum (1 -500) = 16953 Tflops • 31% in Europe, 59% in North America • 1 Flops = 1 floating point operation per second • 1 Tera. Flops = 1000 Giga. Flops
How it grows ? • in 1993 (prehistoric times!) – n° 1 : 59. 7 GFlops – n° 500 : 0. 4 Gflops – Sum = 1. 17 TFlops • in 2004 (yesterday) – n° 1 : 70 TFlops (x 1118) – n° 500 : 850 Gflops (x 2125) – Sum = 11274 Tflops and 408629 processors
2007/11 best : http: //www. top 500. org/ Peak: 596 Tflops !!! http: //www. top 500. org/
2008/11 best : http: //www. top 500. org/ Peak: 1457 Tflops !!! http: //www. top 500. org/
2009/11 best : http: //www. top 500. org/ Peak: 2331 Tflops !!! http: //www. top 500. org/
Performance evolution
Projected performance
Architecture distribution
Interconnection network distribution
NEC earth simulator (1 er en 2004 ; 30ème en 2007) Single stage crossbar : 2700 km of cables A MIMD with Distributed Memory 700 TB disk space 1. 6 PB mass storage area : 4 tennis court, 3 floors
NEC earth simulator
Blue. Gene • 212992 processors – 3 D torus • Rmax = 478 Tflops ; Rpeak = 596 Tflops
Road. Runner • • 3456 nodes (18 clusters) - 2 stage fat tree Infiniband (optical) 1 node= 2 AMD Opteron Dual. Core + 4 IBM Power. XCell 8 i Rmax = 1. 1 Pflops ; Rpeak = 1. 5 Pflops 3, 9 MW (0, 35 Gflops/W)
Jaguar • 224162 cœurs – Mémoire : 300 To – Disque : 10 Po • AMD x 86_64 Opteron Six Core 2600 MHz (10. 4 GFlops) • Rmax = 1759 – Rpeak = 2331 • Power : 6, 950 MW • http: //www. nccs. gov/jaguar/
Network computing • From LAN (cluster) computing to WAN computing • Set of machines distributed over a MAN/WAN that are used to execute parallel loosely coupled codes • Depending on the infrastructure (soft and hard), network computing is derived in Internet computing, P 2 P, Grid computing, etc.
Meta computing (beginning 90’s) • Definitions become fuzzy. . . • A meta computer = set of (widely) distributed (high performance) processing resources that can be associated for processing a parallel not so loosely coupled code • A meta computer = parallel virtual machine over a distributed system SAN LAN Cluster of PCs WAN SAN Cluster of PCs Supercomputer Visualization
Internet computing • Use of (idle) computer interconnected by Internet for processing large throughput applications • Ex : SETI@HOME – 5 M+ users since launching – 2009/11 : 930 k users, 2. 4 M computers; 190 k active users, 278 k active computers, 2 M years of CPU time – 234 « countries » – 1021 floating point operations since 1999 – 769 Tflop/s! – BOINC infrastructure (Décrypthon, RSA 155…) • Programmer view : a single master, n servants
Global computing • Internet computing on a pool of sites • Meta computing with loosely coupled codes • Grid computing with poor communication facilities • Ex : Condor (invented in the 80’s)
Peer to peer computing • A site is both client and server : servent • Dynamic servent discovery by « contamination » • 2 approaches : – centralized management : Napster, Kazaa, e. Donkey… – distributed management : Gnutella, KAD, Freenet, bittorrent… • Application : file sharing
Grid computing (1) “coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organisations” (I. Foster)
Grid computing (2) • Information grid – large access to distributed data (the Web) • Data grid – management and processing of very large distributed data sets • Computing grid – meta computer • Ex : Globus, Legion, UNICORE…
Parallelism vs grids : some recalls • Grids date back “only” 1996 • Parallelism is older ! (first classification in 1972) • Motivations : – need more computing power (weather forecast, atomic simulation, genomics…) – need more storage capacity (petabytes and more) – in a word : improve performance ! 3 ways. . . Work harder Work smarter Get help --> --> Use faster hardware Optimize algorithms Use more computers !
The performance ? Ideally it grows linearly • Speed-up : – if TS is the best time to process a problem sequentially, – its time should be TP=TS/P with P processors ! – Speedup = TS/TP – limited (Amdhal law): any program has a sequential and a parallel part TS=F+T//, – thus the speedup is limited : S = (F+T//)/(F+T///P)<1/F • Scale-up : – if TPS is the time to treat a problem of size S with P processors, – then TPS should also be the time to treat a problem of size n*S with n*P processors
Grid computing
Starting point • Real need for very high performance infrastructures • Basic idea : share computing resources – “The sharing that the GRID is 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 resourcebrokering strategies emerging in industry, science, and engineering” (I. Foster)
Applications • Distributed supercomputing • High throughput computing • On demand (real time) computing • Data intensive computing • Collaborative computing
An Example Virtual Organization: CERN’s Large Hadron Collider Worldwide LHC Computing Grid (WLCG) 1800 Physicists, 140 Institutes, 33 Countries 10 PB of data per year ; 50, 000 CPUs?
LCG System Architecture • Modèle de calcul sur 4 étages – Tier-0: CERN: accélérateur • Acquisition de données et reconstruction • Distribution des données aux Tier-1 (~online) – Tier-1 • Accès et disponibilité 24 x 7, • Acquisition de données quasi-online • Service de données sur la grille: enregistrement utilisant un service de « mass storage » • Analyse-Lourde des données • ~10 pays – Tier-2 Tier-0 (1) Tier-1 (11) Tier-2 (~150) Tier-3 (~50) LHC 40 millions de collisions par seconde ~100 collisions d’intérêt par seconde après filtrage 1 -10 MB de données pour chaque collision – Tier-3 Taux d’acquisition: 0. 1 à 1 GB/sec • Utilisateur final, analyse scientifique 1010 collisions enregistrées chaque année ~10 Peta. Bytes/an • Simulation • Utilisateur final, analyses donnéesen batch et en Interactif • ~40 Pays
LCG System Architecture (suite) Trigger and Data Acquisition System Tier-0 Tier-1 10 Gbps links Optical Private Network (to almost all sites) Tier-2 General Purpose/Academic/ Research Network From F. Malek – LCG FRance
Back to roots (routes) • Railways, telephone, electricity, roads, bank system • Complexity, standards, distribution, integration (large/small) • Impact on the society : how US grown • Big differences : – – clients (the citizens) are NOT providers (State or companies) small number of actors/providers small number of applications strong supervision/control
Computational grid • “Hardware and software infrastructure that provides dependable, consistent, pervasive and inexpensive access to high-end computational capabilities” • Performance criteria : – – – – security reliability computing power latency throughput scalability services
Some recalls about parallelism
Sources of parallelism R 1 R 2 ---> pipeline parallelism ---> intra-operator parallelism ---> inter-query parallelism
Parallel Execution Plan (PEP) PARALLEL EXECUTION PLAN “Scenario” of the query processing Define the role played by every processor and its interaction with the other ones Plan model Cost Model Search heuristics Search space
Intrinsic limitations • Startup time • Contentions : – concurrent accesses to shared resources – sources of contention : • • architecture data partitioning communication management execution plan • Load imbalance – response time = slowest process – NEED to balance data, IO, computations, comm.
Parallel Execution Scenario ---> Operator processing ordering ---> degree of inter-operation parallelism ---> access method (e. g. indexed access) ---> characteristics of intermediate relations (e. g. cardinality) ---> degree of intra-operation parallelism ---> algorithm (e. g. hybrid hash join) ---> redistribution procedures ---> synchronizations ---> scheduling ---> mapping ---> control strategies
Execution control Precisely planning the processing of a query is impossible ! Global and partial Information Dynamic parameters Mandatory to control the execution and to dynamically re-optimize the plan Load balancing Re-parallelization
End of recalls…
Levels of cooperation in a computing grid • End system (computer, disk, sensor…) – multithreading, local I/O • Cluster (heterogeneous) – synchronous communications, DSM, parallel I/O – parallel processing • Intranet – heterogeneity, distributed admin, distributed FS and databases – low supervision, resource discovery – high throughput • Internet – no control, collaborative systems, (international) WAN – brokers, negotiation
Grid characteristics • • Large scale Heterogeneity Multiple administration domain Autonomy… and coordination Dynamicity Flexibility Extensibility Security
Basic services • • • Authentication/Authorization/Traceability Activity control (monitoring) Resource discovery Resource brokering Scheduling Job submission, data access/migration and execution • Accounting
Layered Grid Architecture (By Analogy to Internet Architecture) “Coordinating multiple resources”: ubiquitous infrastructure services, app-specific distributed services “Sharing single resources”: negotiating access, controlling use Collective Application Resource “Talking to things”: communication (Internet protocols) & security Connectivity Transport Internet “Controlling things locally”: Access to, & control of, resources Fabric Link From I. Foster Internet Protocol Architecture Application
Aspects of the Problem • Need for interoperability when different groups want to share resources – – • Need for shared infrastructure services to avoid repeated development, installation – – • Diverse components, policies, mechanisms E. g. , standard notions of identity, means of communication, resource descriptions E. g. , one port/service/protocol for remote access to computing, not one per tool/application E. g. , Certificate Authorities: expensive to run A common need for protocols & services From I. Foster
Resources • • Description Advertising Cataloging Matching Claiming Reserving Checkpointing
Resource layers • Application layer – tasks, resource requests • Application resource management layer – intertask resource management, execution environment • System layer – resource matching, global brokering • Owner layer – owner policy : who may uses what • End-resource layer – end-resource policy (e. g. O. S. )
Resource management (1) • Services and protocols depend on the infrastructure • Some parameters – – stability of the infrastructure (same set of resources or not) freshness of the resource availability information reservation facilities multiple resource or single resource brokering • Example request : I need from 10 to 100 CE each with at least 128 MB RAM and a computing power of 50 Mips
Resource management and scheduling (1) • Levels of scheduling – job scheduling (global level ; perf : throughput) – resource scheduling (perf : fairness, utilization) – application scheduling (perf : response time, speedup, produced data…) • Mapping/scheduling – – – resource discovery and selection assignment of tasks to computing resources data distribution task scheduling on the computing resources (communication scheduling)
Resource management and scheduling (2) • Individual perfs are not necessarily consistent with the global (system) perf ! • Grid problems – predictions are not definitive : dynamicity ! – Heterogeneous platforms – Checkpointing and migration
A Resource Management System example (Globus) RSL specialization Broker RSL Resource Specification Language Queries & Info Application Ground RSL Information Service Co-allocator Simple ground RSL Local resource managers GRAM LSF Condor NQE LSF : Load Sharing Facility (task scheduling and load balancing; Developed by Platform Computing) NQE : Network Queuing Env. (batch management; developed by Cray Research
Resource information (1) • What is to be stored ? – virtual organizations, people, computing resources, software packages, communication resources, event producers, devices… – what about data ? ? ? • A key issue in such dynamics environments • A first approach : (distributed) directory (LDAP) – – – – easy to use tree structure distribution static mostly read ; not efficient updating hierarchical poor procedural language
Resource information (2) • But : – – dynamicity complex relationships frequent updates complex queries • A second approach : (relational) database
Programming on the grid : potential programming models • • Message passing (PVM, MPI) Distributed Shared Memory Data Parallelism (HPF, HPC++) Task Parallelism (Condor) Client/server - RPC Agents Integration system (Corba, DCOM, RMI)
Program execution : issues • Parallelize the program with the right job structure, communication patterns/procedures, algorithms • Discover the available resources • Select the suitable resources • Allocate or reserve these resources • Migrate the data • Initiate computations • Monitor the executions ; checkpoints ? • React to changes • Collect results
Data management • It was long forgotten !!! • Though it is a key issue ! • Issues : – – – indexing retrieval replication caching traceability (auditing) • And security !!!
Bruni, pas Bruni. E !!!
From computing grids to information grids
From computing grids to information grids (1) • Grids lack most of the tools mandatory to share (index, search, access), analyze, secure, monitor semantic data (information) • Several reasons : – history – money – difficulty • Why is it so difficult ? – Sensitivity but openness – Multiple administrative domains, multiple actors, heterogeneousness but a single global architecture/view/system – Dynamicity and unpredictability but robustness – Wideness but high performance
From computing grids to information grids (2) ex: Replica Management Problem • Maintain a mapping between logical names for files and collections and one or more physical locations • Decide where and when a piece of data must be replicated • Important for many applications • Example: CERN high-level trigger data – – – • Multiple petabytes of data per year Copy of everything at CERN (Tier 0) Subsets at national centers (Tier 1) Smaller regional centers (Tier 2) Individual researchers have copies of pieces of data Much more complex with sensitive and complex data like medical data !!!
From computing grids to information grids (3): some (still…) open issues • Security, security (incl. privacy, monitoring, traceability…)) at a semantic level • Access protocols (incl. replication, caching, migration…) • Indexing tools • Brokering of data (incl. accounting) • (Content-based) Query optimization and execution • Mediation of data • Data integration, data warehousing and analysis tools • Knowledge discovery and data mining
Functional View of Grid Data Management Application Metadata Service Planner: Data location, Replica selection, Selection of compute and storage nodes Replica Location Service Information Services Location based on data attributes Location of one or more physical replicas State of grid resources, performance measurements and predictions Security and Policy Executor: Initiates data transfers and computations Data Movement Data Access Compute Resources Storage Resources Un peu simpliste, quand même…
Grid Security (1) Why Grid Security is Hard • Resources being used may be extremely valuable & the problems being solved extremely sensitive • Resources are often located in distinct administrative domains – Each resource may have own policies & procedures • Users may be different • The set of resources used by a single computation may be large, dynamic, and/or unpredictable – Not just client/server • The security service must be broadly available & applicable – Standard, well-tested, well-understood protocols – Integration with wide variety of tools
Grid Security(2) Various views User View Resource Owner View 1) Easy to use 1) Specify local access control 2) Single sign-on 2) Auditing, accounting, etc. 3) Run applications ftp, ssh, MPI, Condor, Web, … 3) Integration w/ local system Kerberos, AFS, license mgr. 4) User based trust model 4) Protection from compromised resources 5) Proxies/agents (delegation) Developer View API/SDK with authentication, flexible message protection, flexible communication, delegation, . . . Direct calls to various security functions (e. g. GSS-API) Or security integrated into higher-level SDKs: E. g. Globus. IO, Condor
Grid security (3) Requirements • • Authentication Authorization and delegation of authority Assurance Accounting Auditing and monitoring Traceability Integrity and confidentiality
Access to data and Mediation • • Ciel, where are the data ? Use case : German tourist – heart accident in Nice Data inside the grid # data at the side of the grid ! Basic idea – use of metadata/indexes. Pb : indexes are (sensitive) information • Alternative – encrypted indexes, use of views, proxies DSEM/DM 2 • Mediation – no single view of the world mechanisms for interoperability, ontologies • Negotiation : a key open issue
Caching • Motivation : – Collaborative caching is proved to be efficient – Each institution wants to control the access to its data – No standard exists in Grids for caching • Proposal : – use metadata to collaborate / index data – a two-level cache : local caches and a global virtual cache – a single access point to internal data (proxy)
Query optimization and execution • Old wine in new bottles ? • Yes and no : it seems the problem has not changed but the operational context has so changed that classical heuristics and methods are not more pertinent • Key issues : – Dynamicity – Unpredictability – Adaptability • Very few works have specifically addressed this problem
An application example : GGM Grille Geno-Medicale
An application example: GGM Biomedical grids • Biomedical applications are perfect candidates for gridification: – – Huge volumes of data (an hospital = several TB per year) Dissemination of data Collaborative work (health networks) Very hard requirements (e. g. response time) • But – Partially structured semantic data – Very strong privacy issues … a perfect play field for researchers !
An application example: GGM Motivation (1) • Dissemination of new “high bandwidth” technologies in genome and proteome research (e. g. micro-arrays) – huge volume of structural (gene localization) – functional (gene expression) data • Generalization of digital patient files and digital medical images • Implementation of (regional and inter-national) health networks • All information is available, people are connected to the network. • The question is : How can we use it ?
An application example: GGM Motivation (2) • Need for an information infrastructure to – index, exchange/share, process all this data – while preserving their privacy at a very large scale • That is. . . just a good grid! • Application objectives: – correlation of genomic and medical data: fundamental research and later medical decision making process – patient-centered medical data integration: patient’s monitoring in and out-side the hospital – epidemiology – training
An application example: GGM Motivation (3) • References: “Synergy between medical informatics and bioinformatics: facilitating genomic medicines for future healthcare”, – BIOINFOMED Working Group, Jan. 2003, European Commission • Proceedings of the first and second Healthgrid conferences (Lyon 2003, Clermont-Ferrand 2004, Oxford 2005, Valence 2006)
An application example: GGM Scope “The goal of the GGM project is, on top of a grid infrastructure, to propose a software architecture able to manage heterogeneous and dynamic data stored in distributed warehouses for intensive analysis and processing purposes. ” • • Distributed Data Warehouses Query Optimization Data Access [and control] Data Mining
An application example: GGM Coming back: semantic data ? • A medical piece of data (age, image, biological result, salient object in an image) has a meaning – conveys information that can be (differently) interpreted • Meta-data can be attached to medical data… or not – pre-processing is necessary • Medical data are often private – privacy/delegation • The medical data of a patient are often disseminated over multiple sites – access rights/authentication problem, collection/integration of data into partial views, identification of data/users • Medical (meta-)data are complex and not yet standardized – no global structure
An application example: GGM Architecture DW-GUI GGM DW OQS NDS DM Patate DA+Cache wrappers Grid Middlware Experiments GO Medical
Virtual data warehouses on the grid
Virtual data warehouse on the grid (1) • Almost nothing… • Why is it so difficult ? – – – – multiple administrative domains very sensitive data => security/privacy issues wide distribution unpredictability relationship with data replica heterogeneity dynamicity (permanent production of large volumes of data) • Centralized data warehouse ? – Not realistic at a large scale and not acceptable
Virtual data warehouse on the grid (2) • A possible direction of research : virtual data warehouses on the grid • Components : – a federated schema – a set of partial views (“chunks”)materialized at the local system level • Advantages – – Flexibility wrt users’ needs Good use of the storage capacity of the grid and scalability Security control at the local level Global view of the disseminated data
Virtual data warehouse on the grid (3) • Drawbacks and open issues – – maintenance protocols indexing tools access to data and negotiation query processing • Use of mobile agents ?
Access to data and collaborative brokers
Access to data and collaborative brokers (1) • Brokers act as interfaces between data, services and applications • Possible locations – – at the interface between the grid and the external data repositories on the grid storage elements at the interface between the grid and the user inside the network (e. g. routers) • Open issues – – – caching : computation results, query partial results… data indexing prefetching user’s customization inter brokers collaboration a key issue : security and privacy
Access to data and collaborative brokers (2) : security and privacy • Medical data belong to the patient that should be able to give access rights to who he wants • To whom processed (even anonymous) data belong to ? • How one can combine privacy and dissemination/ replication/caching ? • What about traceability ?
Datamining and knowledge extraction on the grid
Datamining and knowledge extraction on the grid • Structure of the data : few records, many attributes • Parallelizing data mining algorithms for the grid – volatility of the resources (data, processing) – fault tolerance, checkpointing – distribution of the data : local data exploration + aggregation function to converge towards a unified model – incremental production of the data => active data mining techniques
A short overview of some grid middlewares
The Legion system • University of Virginia • Object-oriented approach. Objects = data, applications, sensors, computing resources, codes… : all is object ! • Loosely coupled codes • Single naming space • Reuse of existing OS and protocols ; definition of message formats and high level protocols • Core objects : naming, binding, object creation/activation/destruction • Methods : description via an IDL • Security : in the hands of the users • Resource allocation : a site can define its own policy
High-Throughput Computing: Condor • High-throughput computing platform for mapping many tasks to idle computers • Since 1986 ! • Major components – A central manager manages pool(s) of [distributively owned or dedicated] computers. A CM = scheduler + coordinator – DAGman manages user task pools – Matchmaker schedules tasks to computers using classified ads – Checkpointing and process migration – No simple communications • Parameter studies, data analysis • Condor married Globus : Condor-G • Several hundreds of Condor pools in the world ; or on your machine !
Defining a DAG • A DAG is defined by a. dag file, listing each of its nodes and their dependencies: # diamond. dag Job A a. sub Job B b. sub Job C c. sub Job D d. sub Parent A Child B C Parent B C Child D Job A Job B Job C Job D • Each node will run the Condor job specified by its accompanying Condor submit file From Condor tutorial
Executing jobs => placing data ! The Storck approach The Stork approach • Storck • STORK: Making Data Placement a First Class Citizen in the Grid : Tevfik Kosar and Miron Livny, University of Wisconsin-Madison, ICDCS’ 2004, Tokyo, Japan
The Globus toolkit • A set of integrated executable management (GEM) services for the Grid • Services – – – – – resource management (GRAM-DUROC) communication (NEXUS - MPICH-G 2, globus_io) information (MDS) data management (replica catalog) security (GSI) monitoring (HBM) remote data access (GASS - Grid. FTP - RIO) executable management (GEM) execution commodity Grid Kits (Java, Python, Corba, Matlab…)
Components in Globus Toolkit 3. 0 GSI WU Grid. FTP Pre-WS GRAM WS-Security RFT (OGSI) WS GRAM (OGSI) MDS 2 JAVA WS Core (OGSI) WS-Index (OGSI) OGSI C Bindings RLS Security Data Management Resource Management Information Services WS Core
Components in Globus Toolkit 3. 2 GSI WU Grid. FTP Pre-WS GRAM WS-Security RFT (OGSI) WS GRAM (OGSI) CAS (OGSI) OGSI-DAI WS-Index (OGSI) OGSI C Bindings RLS Simple. CA MDS 2 JAVA WS Core (OGSI) OGSI Python Bindings (contributed) py. Globus (contributed) XIO Security Data Management Resource Management Information Services WS Core
Planned Components in GT 4. 0 GSI New Grid. FTP Pre-WS GRAM WS-Security RFT (WSRF) WS-GRAM (WSRF) CAS (WSRF) RLS WS-Index (WSRF) C WS Core (WSRF) CSF (contribution) Simple. CA MDS 2 JAVA WS Core (WSRF) OGSI-DAI Authz Framework Security py. Globus (contributed) XIO Data Management Resource Management Information Services WS Core
GT 2 GRAM Trusted by server and user Root est Requ nd e, espo ticat en te, R Auth ntica e Auth Requestor Gatekeeper Host Creds Server Invoke Job. Manager User Account
GT 3 GRAM Globus account (non-privileged) Trusted by server MMJFS est qu d Re ne Sig Requestor Invoke Sig ned Root Res Host. Env Starter GRIM pon d Host Creds Server Job. Manager GRIM Creds User Account Trusted by server
GT 4 GRAM • http: //wwwunix. globus. org/toolkit/docs/3. 2/gram/ws/d eveloper/architecture. html
Conclusion (2005) • Just a new toy for scientists or a revolution ? • Huge investments • Classical issues but a functional, operational and applicative context very complex • Complexity from heterogeneity, wide distribution, security, dynamicity • Functional shift from computing to information • Data management in grids : not prehistory, but still middle-ages • Still much work to do !!! • A global framework for grid computing, pervasive computing and Web services ?
Conclusion (2008) • Just a new toy for scientists or a revolution ? Neither of them ! • Huge investments : too much ? ! • Classical issues but a functional, operational and applicative context very complex • Complexity from heterogeneity, wide distribution, security, dynamicity • Functional shift from computing to information • Data management in grids : not middle-ages, but not 21 st century => services • Supercomputing is still alive • A global framework for grid computing, pervasive computing and Web services… and SOA ! • Some convergence between P 2 P and grid computing • The industrialization time
And in 2009, a new paradigm : cloud computing • • • Amazon, Google, Microsoft… even L’Oréal ! Cloud = Internet Resource = service provided by the network Behind the scene : a grid ? ? ? Old wine in a new bottle ? Cf. « exposés »
Скачать презентацию Grid computing an introduction Lionel Brunie Institut
92632a1a93073b66d3c6ab75b95b4804.ppt