Globus Toolkit 4: Current Status and Futures

1
Globus Toolkit 4Current Status and Futures

• Jennifer M. Schopf
• UK National eScience Centre
• Argonne National Lab

2
What is a Grid

• Resource sharing
• Computers, storage, sensors, networks,
• Sharing always conditional issues of trust,
  policy, negotiation, payment,
• Coordinated problem solving
• Beyond client-server distributed data analysis,
  computation, collaboration,
• Dynamic, multi-institutional virtual orgs
• Community overlays on classic org structures
• Large or small, static or dynamic

3
Why is this hard/different?

• Lack of central control
• Where things run
• When they run
• Shared resources
• Contention, variability
• Communication
• Different sites implies different sys admins,
  users, institutional goals, and often strong
  personalities

4
So why do it?

• Computations that need to be done with a time
  limit
• Data that cant fit on one site
• Data owned by multiple sites
• Applications that need to be run bigger, faster,
  more

5
Globus Toolkit wascreated to help applications

• The Globus Toolkit is a collection of solutions
  to problems that frequently come up when trying
  to build collaborative distributed applications
• Heterogeneity
• Focus on simplifying heterogenity for application
  developers
• Working towards more vertical solutions in
  future versions.
• Standards
• Capitalize on and encourage use of existing
  standards (IETF, W3C, OASIS, GGF).
• Reference implementations of new/proposed
  standards in these organizations.

6
With Grid Computing Forget Homogeneity!

• Trying to force homogeneity on users is futile.
  Everyone has their own preferences, sometimes
  even dogma.
• The Internet provides the model

7
Evolution of the Grid
App-specific Services
Open Grid Services Arch
Web services
Increased functionality, standardization
GGF OGSI, WSRF, (leveraging OASIS, W3C,
IETF) Multiple implementations, including Globus
Toolkit
X.509, LDAP, FTP,
Globus Toolkit
Defacto standards GGF GridFTP, GSI (leveraging
IETF)
Custom solutions
Time
8
Globus is Service-Oriented Infrastructure
Technology

• Software for service-oriented infrastructure
• Service enable new existing resources
• E.g., GRAM on computer, GridFTP on storage
  system, custom application service
• Uniform abstractions mechanisms
• Tools to build applications that exploit
  service-oriented infrastructure
• Registries, security, data management,
• Open source open standards
• Each empowers the other
• eg monitoring across different protocols is
  hard
• Enabler of a rich tool service ecosystem

9
Globus Toolkit V4.0

• Major release on April 29th 2005
• Precious fifteen months spent on design,
  development, and testing
• 1.8M lines of code
• Major contributions from five institutions
• Hundreds of millions of service calls executed
  over weeks of continuous operation
• Significant improvements over GT3 code base in
  all dimensions

10
Our Goals for GT4

• Usability, reliability, scalability,
• Web service components have quality equal or
  superior to pre-WS components
• Documentation at acceptable quality level
• Consistency with latest standards (WS-, WSRF,
  WS-N, etc.) and Apache platform
• WS-I Basic (Security) Profile compliant
• New components, platforms, languages
• And links to larger Globus ecosystem

11
(No Transcript)
12
GT4 Components and Performance

• Globus Toolkit Components
• Core
• Security
• Data Management
• Resource Management
• Monitoring
• Performance in the broadest sense of the word.
• How fast
• How many
• How stable
• (How easy)
• www.globus.org/toolkit/docs/4.0/perf_overview.html

13
GT4 Web Services Core

• Supports both Globus services (GRAM, RFT,
  Delegation, etc.) user-developed services
• Redesign to enhance scalability, modularity,
  performance, usability
• Leverages existing WS standards
• WS-I Basic Profile WSDL, SOAP, etc.
• WS-Security, WS-Addressing
• Adds support for emerging WS standards
• WS-Resource Framework, WS-Notification
• Java, Python, C hosting environments

14
Open Source/Open Standards

• WSRF developed in collaboration with IBM
• Currently in OASIS process
• Contributions to Apache for
• WS-Security
• WS-Addressing
• Axis
• Apollo (WSRF)
• Hermes (WS-Notification)

15
Java Core Performance

• Weve been working hard to increase basic
  messaging performance
• Factor of four improvement over GT3 so far
• Reliability
• Core can scale to a very large number of
  resources (gt10,000)

16
Java Core Messaging Performance
17
Why Grid Security is Hard

• Resources being used may be valuable the
  problems being solved sensitive
• Resources are often located in distinct
  administrative domains
• Each resource has own policies procedures
• Set of resources used by a single computation may
  be large, dynamic, and unpredictable
• Not just client/server, requires delegation
• It must be broadly available applicable
• Standard, well-tested, well-understood protocols
  integrated with wide variety of tools

18
Basic Grid Security Mechanisms

• Grid-wide identities implemented as PKI
  certificates
• Transport-level and message-level authentication
• Ability to delegate credentials to agents
• Ability to map between Grid local identities
• Local security administration enforcement
• Single sign-on support implemented as proxies
• A plug in framework for authorization decisions

19
GSI Functions

• Four distinct functions message protection,
  authentication, delegation, and authorization
• Implementations of different standards for each
• TLS (transport-level) or WS-Security and
  WS-SecureConversation (message level) used as
  message protection mech. in combination with SOAP
• X.509 End Entity Certificates or Username and
  Password are used as authentication credentials
• X.509 Proxy Certificates and WS-Trust are used
  for delegation
• SAML assertions are used for authorization
• Stand-alone delegation service
• More authentication options
• MyProxy, simpleCA,

20
Message-level Security

• Provides message protection for SOAP messages
• Support for WS-Security standard and
  WS-SecureConversation specification
• Complies with WS-Interoperability Basic Security
  Profile
• Currently has poor performance
• Unclear if this is an implementation issue ot a
  specification issue

21
Transport-level Security

• Authentication via TLS protocol
• (ietf spec)
• Support for X.509 proxy certificates
• Default in GT4 due to performance concerns,
  driven by user requirements

22
GT4s Use of Security Standards
23
Basic Grid Security Mechanisms

• Basic security mechanisms are provided as
  libraries/classes and APIs.
• Integrated with other GT tools and services
• Integrated with many Grid community tools and
  services (and applications systems)
• A few stand-alone tools are also included.

24
A Cautionary Note

• Grid security mechanisms are tedious to set up.
• If exposed to users, hand-holding is usually
  required.
• These mechanisms can be hidden entirely from end
  users, but still used behind the scenes.
• These mechanisms exist for good reasons.
• Many useful things can be done without Grid
  security.
• It is unlikely that an ambitious project could go
  into production operation without security like
  this.
• Most successful projects end up using Grid
  security, but using it in ways that end users
  dont see much.

25
GT4 Security

• Standards based support for message level and
  transport level security
• Transport level is default due to performance
• Standards based authorization (SAML) via
  Community Authorization Service (CAS) or callouts
• Stand-alone delegation service
• More authentication options
• MyProxy, simpleCA,

26
GT4 Security
Users
27
Security Performance

• Weve measured performance for both WS and
  transport security mechanisms
• See next slide for graph
• Transport security is significantly faster than
  WS security
• We made transport security (i.e. https) our
  default
• Were working on making it even faster by using
  connection caching

28
(No Transcript)
29
A Model Architecture for Data Grids
Attribute Specification
Replica Loc. Svc
Metadata Catalog
Application
Multiple Locations
Logical Collection and Logical File Name
MDS
Selected Replica
Replica Selection
Performance Information Predictions
NWS
GridFTP Control Channel
Disk Cache
GridFTPDataChannel
Tape Library
Disk Array
Disk Cache
Replica Location 1
Replica Location 2
Replica Location 3
30
GT4 Data Management

• Stage large data to/from nodes
• Replicate data for performance reliability
• Locate data of interest
• Provide access to diverse data sources
• File systems, parallel file systems, hierarchical
  storage (GridFTP)
• Databases (OGSA-DAI)

31
GT4 Data Functions

• Find your data Replica Location Service
• Managing 40M files in production settings
• Move/access your data GridFTP, RFT
• High-performance striped data movement
• Couple data execution management
• GRAM uses GridFTP and RFT for staging

32
GridFTP in GT4

• 100 Globus code
• No licensing issues
• Stable, extensible
• IPv6 Support
• XIO for different transports
• Striping ? multi-Gb/sec wide area transport
• Pluggable
• Front-end e.g., future WS control channel
• Back-end e.g., HPSS, cluster file systems
• Transfer e.g., UDP, NetBLT transport

33
GridFTP Performance

• TeraGrid Striping results
• 30Gbs network, 32 IBM ia64 nodes
• Ran varying number of stripes
• Ran both memory-to-memory and disk-to-disk

34
Memory to MemoryStriping Performance

• High linear scalability (slope near 1)
• 27 Gbs on a 30 Gbs link (90 utilization) with 32
  nodes

35
Disk to Disk Striping Performance

• Limited by the storage system
• Achieved 17.5 Gbs

36
And in conversation

• We think we have hit the limit of python code.
  The GridFTP C libraries are delivering data so
  fast to the buffers that the python client code
  cannot keep up in doing the fseek, fwrite, and
  then re-register the data callback. We are going
  to have to code our "transfer agents" entirely in
  C for S5.Not a bad problem to have
• Scott Koranda, Dept of Physics, University of
  Minnesota

37
Reliable File TransferThird Party Transfer

• Fire-and-forget transfer
• Web services interface
• Many files directories
• Integrated failure recovery

RFT Client
SOAP Messages
Notifications(Optional)
RFT Service
GridFTP Server
GridFTP Server
38
RFT Performance Stats

• Current maximum request size is approx 20,000
  entries with a default 64MB heap size.
• Infinite transfer - LAN
• 120,000 transfers (servers were killed by
  mistake)
• Was a good test. Found a corner case where
  postgres was not able to perform 3 update
  queries / sec and was using up CPU
• Infinite transfer WAN
• 67000 transfers (killed because of the same
  reason as above)
• Sloan Digital Sky Survey DR3 archive move
• 900K files, 6 TB
• Killed the transfer several times for
  recoverability testing
• No human intervention has been required to date

39
Replica Location Service

• Identify location of files via logical to
  physical name map
• Distributed indexing of names, fault tolerant
  update protocols
• GT4 version scalable stable
• Managing 40 million files across 10 sites

Index
Index
40
LIGO Use of RLS

• Some hands-on numbers
• Produce 1 TB per day
• 8 sites
• gt 3 million entries in the RLS
• gt 30 million files
• This replication of data using RLS and GridFTP
  is enabling more gravitational wave data analysts
  across the world to do more science more
  efficiently then ever before. Globus RLS and
  GridFTP are in the critical path for LIGO data
  analysis.

41
Data Replication Service (tech preview)

• Pull missing files to local site

Site B
Site A
List of required Files
Reliable File TransferService
Data Replication Service
Data Replication Service
Reliable File Transfer Service
GridFTP
Local ReplicaCatalog
Replica LocationIndex
Local Replica Catalog
ReplicaLocationIndex
GridFTP
42
OGSA-DAI

• Flexible Composable Middleware
• Data access
• Relational XML Databases, semi-structured files
• Data integration
• Multiple data delivery mechanisms, data
  translation
• Extensible Efficient framework
• Request documents contain multiple tasks
• A task execution of an activity
• Group work to enable efficient operation
• Extensible set of activities
• gt 30 predefined, framework for writing your own
• Moves computation to data
• Pipelined and streaming evaluation
• Concurrent task evaluation

43
OGSA-DAI

• Current Release Release 5 in GT4
• Added Installation wizards indexed files
• gt1100 registered users we know about
• Running on 3 message passing infrastructures
• Release 6 May 2005
• Improved client side API
• Explicit control of sequential parallel tasks
• Dynamic reconfigurability
• WS-DAI reference implementation

44
The Resource Management Challenge

• Enabling secure, controlled remote access to
  heterogeneous computational resources and
  management of remote computation
• Authentication and authorization
• Resource discovery characterization
• Reservation and allocation
• Computation monitoring and control
• Addressed by a set of protocols services
• GRAM protocol as a basic building block
• Resource brokering co-allocation services
• GSI for security, MDS for discovery

45
Execution Management (GRAM)

• Common WS interface to schedulers
• Unix, Condor, LSF, PBS, SGE,
• More generally interface for process execution
  management
• Lay down execution environment
• Stage data
• Monitor manage lifecycle
• Kill it, clean up
• A basis for application-driven provisioning

46
GT4 GRAM

• 2nd-generation WS implementation
• optimized for performance, stability,
  scalability
• Streamlined critical path
• Use only what you need
• Flexible credential management
• Credential cache delegation service
• GridFTP RFT used for data operations
• Data staging streaming output
• Eliminates redundant GASS code
• Single and multi-job support

47
GT4 GRAM StructureWSRF/WSN Poster Child
Service host(s) and compute element(s)
GT4 Java Container
Compute element
Local job control
GRAM services
GRAM services
Local scheduler
Job functions
sudo
GRAM adapter
Delegate
Transfer request
Delegation
Client
Delegate
GridFTP
User job
RFT File Transfer
FTP control
FTP data
Remote storage element(s)
GridFTP
48
Some of our Goals

• GRAM should add little to no overhead compared
  to an underlying batch system
• Submit as many jobs to GRAM as is possible to the
  underlying scheduler
• Goal - 10,000 jobs to a batch scheduler
• Goal efficiently fill the process table for
  fork scheduler
• Submit/process jobs as fast to GRAM as is
  possible to the underlying scheduler
• Goal - 1 per second
• We are not there yet
• A range of limiting factors at play

49
Design Decisions

• Efforts and features towards the goal
• Allow job brokers the freedom to optimize
• E.g. Condor-G is smarter than globusrun
• Protocol steps made optional and shareable
• Reduced cost for GRAM service on host
• Single WSRF host environment
• Better job status monitoring mechanisms
• More scalable/reliable file handling
• GridFTP and RFT instead of globus-url-copy
• Removal of non-scalable GASS caching
• GT4 tests performing better than GT3 did
• But more work to do

50
GRAM 3.9.4 performance

• Throughput
• Test Simple job to fork scheduler (/bin/date)
  no staging, streaming, or cleanup
• 77 jobs/min sustained
• 60 jobs/minute with delegation
• Long Running test
• Ran 500,000 sequential jobs over 23 days
• These included staging, delegation, fork job
  manager

51
Gram Performance (2)

• Concurrency
• Job submits to Condor scheduler (long running
  sleep job) no staging, streaming, or cleanup no
  delegation
• Current limit is 32,000 jobs due to a Linux
  directory limit
• using multiple sub-directories will resolve this,
  look for this in 4.2

52
Monitoring and Discovery Challenges

• Grid Information Service
• Requirements and characteristics
• Uniform, flexible access to information
• Scalable, efficient access to dynamic data
• Access to multiple information sources
• Decentralized maintenance
• Secure information provision

53
Monitoring and Discovery

• Every service should be monitorable and
  discoverable using common mechanisms
• WSRF/WSN provides those mechanisms
• A common aggregator framework for collecting
  information from services, thus
• Index Service Registry supporting Xpath queries,
  with caching
• Trigger Service perform action on condition
• Deep integration with Globus containers
  services every GT4 service is discoverable
• GRAM, RFT, GridFTP, CAS,

54
GT4 Monitoring Discovery
Clients (e.g., WebMDS)
GT4 Container
WS-ServiceGroup
Index
Registration WSRF/WSN Access

adapter
GT4 Cont.
GT4 Container
Index
Index
Custom protocols for non-WSRF entities
Automated registration in container
GridFTP
RFT
GRAM
User
55
MDS4 Extensibility

• Aggregator framework provides
• Registration management
• Collection of information from Grid Resources
• Plug in interface for data access, collection
  ,query,
• WebMDS framework provides for customized display
• XSLT transformations

56
With a standard deployment,a project can

• Discover needed data from services in order to
  make job submission or replica selection
  decisions by querying the VO-wide Index
• Evaluate the status of Grid services by looking
  at the VO-wide WebMDS setup
• Be notified when disks are full or other error
  conditions happen by being on the list of
  administrators
• Individual projects can examine the state of the
  resources and services of interest to them

57
Some Performance Numbers

• Basic Index Server Performance
• How long does one response take?
• How many responses per minute are possible?
• How long does the service stay up while being
  used before failing?
• The set up
• 5 client nodes (ned0ned4), dedicated
• dual CPU 1133MHz Pentium III machines with 1.5GB
  of RAM
• 1 server node (dc-user2), shared
• dual Intel (hyperthreaded) Xeon, 2.20GHz with 1GB
  of RAM
• Interconnected by Gigabit Ethernet, same physical
  switch

58
Index Server Performance (3.9.4)
 
59
Index Server Performance

• As the MDS4 Index grows, query rate and response
  time both slow, although sublinearly
• Response time slows due to increasing data
  transfer size
• Full Index is being returned
• Response is re-built for every query
• Real question how much over simple WS-N
  performance?

60
MDS4 compared to other systems
61
Index Server Stability

• Zero-entry index on same server
• Ran queries against it for 1,225,221 seconds
  (just over 2 weeks)
• (server machine was accidentally rebooted)
• Processed 93,890,248 requests
• Avg 76 per second
• Average query round-trip time of 13ms
• No noticeable performance or usability
  degradation over the entire duration of the test

62
GT4 Documentationis Much Improved!
63
The Globus Ecosystem

• Globus components address core issues relating to
  resource access, monitoring, discovery, security,
  data movement, etc.
• GT4 being the latest version
• A larger Globus ecosystem of open source and
  proprietary components provide complementary
  components
• A growing list of components
• These components can be combined to produce
  solutions to Grid problems
• Were building a list of such solutions

64
2005 and Beyond

• We have a solid Web services base
• We now want to build, on that base, a open source
  service-oriented infrastructure
• Virtualization
• New services for provisioning, data management,
  security, VO management
• End-user tools for application development
• Etc., etc.

65
Next Step Plans

• Support!
• Actively working with user groups to make sure
  their deployments are stable
• Move everyone from GT2 and GT3 to GT4
• Continue to improve documentation
• Goal every support question gets put into the
  docs

66
Short-Term Priorities Core

• Streamlined container configuration
• Remote management interface
• Dynamic service deployment
• Service isolation multiple service instances
• WS-Notification, subscription performance
• Full functionality in C WS Core
• Optimized WS-ServiceGroup support
• WS-SecureConversation support

67
Short-Term Priorities Core

• Streamlined container configuration
• Remote management interface
• Dynamic service deployment
• WS-Notification, subscription performance
• Full functionality in C WS Core
• Optimized WS-ServiceGroup support
• WS-SecureConversation support

68
Short-Term Priorities Security

• Improve GSI error reporting diagnostics
• Secure password, one-time password, Kerberos
  support for initial log on
• Trust roots, use of GridLogon
• Identity/attribute assertions in GT auth.
  callouts (e.g., Shib, PERMIS, VOMS, SAML)
• Extend CAS admin policy support
• Security logging with management control for
  audit purposes

69
Data Management PriorityReliable, Managed
Access to Data

• Functionality to run at a chosen bandwidth
• Limiting total max bandwidth
• Limiting total number of server instances that
  can run concurrently
• Being able to pre-allocate space for a file
  before it starts to transfer
• not reservations, send ALLO ltfile sizegt, server
  gets block of space that size or returns an
  error.
• Hierarchical front ends
• Scale to hundreds or thousands of machines and
  many millions of files
• Admin interface to the server so that a
  user/admin can speed up, slow down, suspend, or
  cancel a transfer

70
Short-Term Priorities Data Management

• Concurrency in globus-url-copy
• Priorities in RFT
• Data replication service
• Enhance policy support in data services
• Physical file name creation service
• Scalable distributed metadata manager
• OGSA-DAI will become a core component

71
WS GRAM as a reliablemanageable resource

• Additional controls to limit the number of
  threads doing work in order limit resource
  consumption
• Policy-driven restart of persistent jobs
• Improved information collection for jobs
• Improved management of job collections
• Credential refresh
• WS GRAM version of globus-job-run/submit
• Implement GGF JSDL once finalized
• Advanced reservation support

72
Short-Term Priorities Execution Management

• Virtual workspace service
• Integration of virtual machines (Xen, VMware) and
  associated services

73
Short-Term Priorities Information Services

• Many more information sources, including gateways
  to other systems
• Automated configuration of monitoring
• Specialized monitoring displays
• Performance optimization of registry
• Archiver service
• Helper tools to streamline integration of new
  information sources

74
The Globus Developer Community

• We want to facilitate community contributions to
  the Globus software
• Increasingly open governance mechanisms
• Documentation of larger ecosystem
• What else can we do?
• Tell us how you think we should evolve
• E.g., adopt Apache processes?
• Contribute more of Globus to Apache?
• Weve already made major contributions to Apache
  Axis, WS-Addressing, and WS-Security
• Also WSRF/WSN ? Apache (Apollo, Hermes)

75
Globus and its User Community

• How can we best support you?
• We try to provide the best software we can
• We use bugzilla other community tools
• We work to grow the set of contributors
• How can you best support us?
• Become a contributor of software, bug fixes,
  answers to questions, documentation
• Provide us with success stories that can justify
  continued Globus development
• Tell us what your performance requirements are!
• Promote Globus within your communities
• Contact me at jms_at_mcs.anl.gov

76
So

• GT4 is a significant step forward in the quality,
  functionality and standards compliance of GT.
• Final release now available
• Downloads and docs at
• www.globus.org/toolkit

2nd Edition www.mkp.com/grid2
77
References

• Jennifer M. Schopf
• jms_at_mcs.anl.gov
• www.mcs.anl.gov/jms
• Support from DOE, NSF, NeSC
• This talk
• www.mcs.anl.gov/jms/Talks (not there yet)
• Globus Alliance
• www.globus.org
• Globus Performance
• www.globus.org/toolkit/docs/4.0/perf_overview.html

78
How Globus Works

• Globus is a distributed open source community
  with many contributors users
• CVS, documentation, bugzilla, email lists
• Modular structure allows many to contribute
• Globus Alliance Board provides governance when
  needed
• Meritocracy individuals who demonstrate ongoing
  contributions commitment
• Primarily what to include, when to release
• Globus Alliance is an informal partnership of
  organizations led by Board members

79
Evolution of the Globus Alliance

• Argonne/U.Chicago (Childers, Foster) 1995
• USC/ISI (Kesselman) 1995
• Edinburgh (Atkinson, Parsons) 2003
• Swedish PDC (Johnsson, Mulmo) 2003
• NCSA (Welch) 2004
• Univa (Czajkowski, Tuecke) 2004
• Other contributors will surely be added

80
From eScience to eBusiness

• Since 2001, growing interest in Globus for
  commercial use
• Enterprises, IT vendors, ISVs asking Globus
  leaders to address commercial needs
• But hard to do in a research laboratory
• In response, we have created two new
  organizations
• Globus Consortium
• Univa

81
Globus Consortium(www.globusconsortium.com)

• Nonprofit organization funded by companies to
  advance Globus Toolkit for enterprise use
• Initial sponsor members HP, IBM, Intel, Sun
• Initial contributors Nortel, Univa
• First two projects already identified
• Member-driven software quality improvements
• Contributions to job submission standards
• Other projects to be defined, e.g.
• Develop new features key to enterprise use
• Education outreach

82

• Provider of commercial support, services,
  products around open source Globus
• Commercial distribution of GT4 beyond
• Integration with enterprise systems
• Committed to open source open standards
• Founded by Tuecke, Foster, Kesselman
• Tuecke left Argonne to be CEO
• Foster, Kesselman remain at Argonne, ISI
• Experienced management team
• Rich Miller, Vas Vasiliadis, Paul Davé, Bob
  Mandel

83

• 26776 U.S.
• 2753 China
• 1318 Japan
• 1017 India
• 750 U.K.
• 495 Italy
• 488 Germany
• 391 Brazil
• 328 S. Korea
• 306 Taiwan
• 268 France
• 241 Canada
• 211 Viet Nam
• 211 Spain
• 202 Russia
• 187 Pakistan
• 159 Australia
• 142 Singapore
• 131 Greece

68 Belgium 66 Venezuela 66 Romania 64
Indonesia 62 Mexico 61 Turkey 60 Malaysia 58
Portugal 57 Austria 54 Ireland 44 Hong Kong
40 Hungary 38 Egypt 38 Argentina 34 Uruguay
31 Ukraine 29 Slovakia 25 Israel 23
Yugoslavia 23 Iran 22 Bulgaria 22 Uzbekistan
22 Czech Rep. 22 N. Korea 21 Lithuania 21
Croatia
20 Finland 20 New Zealand 17 Nigeria 17 South
Africa 16 Jordan 16 Slovenia 16 Afghanistan
15 Denmark 15 Philippines 14 Vanuatu 14
Luxembourg 14 Tunisia 12 Virgin Is. (U.K.) 12
Peru 12 Yemen 11 Norway 11 Algeria 11 Armenia
10 Iceland 9 Zambia 9 Virgin Is. (U.S.) 9
Uganda 9 Bosnia Herz. 8 Kenya 7 Zimbabwe 7
Saudi Arabia
7 Ecuador 7 Macedonia 6 Bolivia 6 Comoros 6
Zaire 6 Lebanon 5 Puerto Rico 5 Namibia 5
Togo 5 Tajikistan 5 Paraguay 5 Albania 5
Sudan 4 Estonia 4 Camaroon 4 Ghana 4 Tuvalu
4 Costa Rica 4 Cuba 4 UAE 4 Tonga 4 W. Samoa
4 Tanzania 3 Syria 3 Bahamas 3 Ethiopia
3 Mongolia 3 Sri Lanka 3 Wallis Futuna Is. 3
Belarus 3 Bangladesh 2 Falkland Islands 2
Kuwait 2 Sierra Leone 2 Trinidad Tobago 2
Guyana 2 American Samoa 2 Andorra 2 Georgia 2
Cook Islands 2 Turkmenistan 2 Gabon 2 The
Gambia 2 Kazakhstan 2 Macau 2 Malta 2 Jamaica
2 Latvia 2 Turks Caicos 1 Bhutan 1 Ascension
Island 1 Cyprus
1 Mozambique 1 Tokelau 1 Greenland 1 Nepal 1
Swaziland 1 Iraq 1 Serbia 1 Barbados 1
Cambodia 1 Qatar 1 Saint Vincent 1 Laos 1 San
Marino 1 Libya 1 Benin 1 Angola 1 Chad 1
Gibraltar 1 Haiti 1 Guatemala 1 Malawi 1
Equatorial Guinea 1 Palau 1 Bermuda 1 Botswana
1 Suriname
38669 downloads in 2004 from globus.org
84

• 26776 U.S.
• 2753 China
• 1318 Japan
• 1017 India
• 750 U.K.
• 495 Italy
• 488 Germany
• 391 Brazil
• 328 S. Korea
• 306 Taiwan
• 268 France
• 241 Canada
• 211 Viet Nam
• 211 Spain
• 202 Russia
• 187 Pakistan
• 159 Australia
• 142 Singapore
• 131 Greece

68 Belgium 66 Venezuela 66 Romania 64
Indonesia 62 Mexico 61 Turkey 60 Malaysia 58
Portugal 57 Austria 54 Ireland 44 Hong Kong
40 Hungary 38 Egypt 38 Argentina 34 Uruguay
31 Ukraine 29 Slovakia 25 Israel 23
Yugoslavia 23 Iran 22 Bulgaria 22 Uzbekistan
22 Czech Rep. 22 N. Korea 21 Lithuania 21
Croatia
20 Finland 20 New Zealand 17 Nigeria 17 South
Africa 16 Jordan 16 Slovenia 16 Afghanistan
15 Denmark 15 Philippines 14 Vanuatu 14
Luxembourg 14 Tunisia 12 Virgin Is. (U.K.) 12
Peru 12 Yemen 11 Norway 11 Algeria 11 Armenia
10 Iceland 9 Zambia 9 Virgin Is. (U.S.) 9
Uganda 9 Bosnia Herz. 8 Kenya 7 Zimbabwe 7
Saudi Arabia
7 Ecuador 7 Macedonia 6 Bolivia 6 Comoros 6
Zaire 6 Lebanon 5 Puerto Rico 5 Namibia 5
Togo 5 Tajikistan 5 Paraguay 5 Albania 5
Sudan 4 Estonia 4 Camaroon 4 Ghana 4 Tuvalu
4 Costa Rica 4 Cuba 4 UAE 4 Tonga 4 W. Samoa
4 Tanzania 3 Syria 3 Bahamas 3 Ethiopia
3 Mongolia 3 Sri Lanka 3 Wallis Futuna Is. 3
Belarus 3 Bangladesh 2 Falkland Islands 2
Kuwait 2 Sierra Leone 2 Trinidad Tobago 2
Guyana 2 American Samoa 2 Andorra 2 Georgia 2
Cook Islands 2 Turkmenistan 2 Gabon 2 The
Gambia 2 Kazakhstan 2 Macau 2 Malta 2 Jamaica
2 Latvia 2 Turks Caicos 1 Bhutan 1 Ascension
Island 1 Cyprus
1 Mozambique 1 Tokelau 1 Greenland 1 Nepal 1
Swaziland 1 Iraq 1 Serbia 1 Barbados 1
Cambodia 1 Qatar 1 Saint Vincent 1 Laos 1 San
Marino 1 Libya 1 Benin 1 Angola 1 Chad 1
Gibraltar 1 Haiti 1 Guatemala 1 Malawi 1
Equatorial Guinea 1 Palau 1 Bermuda 1 Botswana
1 Suriname
Top 10
26776 U.S. 2753 China 1318 Japan 1017
India 750 U.K. 495 Italy 488
Germany 391 Brazil 328 S. Korea 306
Taiwan
38669 downloads in 2004 from globus.org
85
GlobalCommunity
86
The Globus Ecosystem

• Globus components address core issues relating to
  resource access, monitoring, discovery, security,
  data movement, etc.
• GT4 being the latest version
• A larger Globus ecosystem of open source and
  proprietary components provide complementary
  components
• A growing list of components
• These components can be combined to produce
  solutions to Grid problems
• Were building a list of such solutions

87
Many Tools Build on, or Can Contribute to,
GT4-Based Grids

• Condor-G, DAGman
• MPICH-G2
• GRMS
• Nimrod-G
• Ninf-G
• Open Grid Computing Env.
• Commodity Grid Toolkit
• GriPhyN Virtual Data System
• Virtual Data Toolkit
• GridXpert Synergy
• Platform Globus Toolkit

• VOMS
• PERMIS
• GT4IDE
• Sun Grid Engine
• PBS scheduler
• LSF scheduler
• GridBus
• TeraGrid CTSS
• NEES
• IBM Grid Toolbox

88
DocumentingThe Grid Ecosystem
The Grid Ecosystem Software Components for Grid
Systems And Applications
www.grids-center.org
89
Example Solutions

• Portal-based User Reg. System (PURSE)
• VO Management Registration Service
• Service Monitoring Service
• TeraGrid TGCP Tool
• Lightweight Data Replicator
• GriPhyN Virtual Data System

90
The Globus Developer Community

• We want to facilitate community contributions to
  the Globus software
• Increasingly open governance mechanisms
• Documentation of larger ecosystem
• What else can we do?
• Tell us how you think we should evolve
• E.g., adopt Apache processes?
• Contribute more of Globus to Apache?
• Weve already made major contributions to Apache
  Axis, WS-Addressing, and WS-Security
• Also WSRF/WSN ? Apache (Apollo, Hermes)

91
Globus and its User Community

• How can we best support you?
• We try to provide the best software we can
• We use bugzilla other community tools
• We work to grow the set of contributors
• How can you best support us?
• Become a contributor of software, bug fixes,
  answers to questions, documentation
• Provide us with success stories that can justify
  continued Globus development
• Promote Globus within your communities
• Contact me at jms_at_mcs.anl.gov

92
Many Tools Build on, or Can Contribute to,
GT4-Based Grids

• Condor-G, DAGman
• MPICH-G2
• GRMS
• Nimrod-G
• Ninf-G
• Open Grid Computing Env.
• Commodity Grid Toolkit
• GriPhyN Virtual Data System
• Virtual Data Toolkit
• GridXpert Synergy

• Platform Globus Toolkit
• VOMS
• PERMIS
• GT4IDE
• Sun Grid Engine
• PBS scheduler
• LSF scheduler
• GridBus
• TeraGrid CTSS
• NEES
• IBM Grid Toolbox

93
So

• GT4 is a significant step forward in the quality,
  functionality and standards compliance of GT.
• Final release now available
• Downloads and docs at
• www.globus.org/toolkit

2nd Edition www.mkp.com/grid2
94
References

• Jennifer M. Schopf
• jms_at_mcs.anl.gov
• www.mcs.anl.gov/jms
• Support from DOE, NSF, Microsoft, NeSC, JISC
• This talk
• www.mcs.anl.gov/jms/Talks (not there yet)
• Globus Alliance
• www.globus.org
• Globus Performance
• www.globus.org/toolkit/docs/4.0/perf_overview.html