Replica Catalog Performance and Capacity Requirements

*Mike Wilde, ANL, Editor*

*Version 1*

*11/14/2023 10:57 AM*

**Revision History**

[V1, 5 June 2001]{.underline}: First version numbered revision. Document
created to explain spreadsheet field and track open issues and
assumptions.

# Introduction

This document contains quantitative requirements for the performance and
capacity of the Globus replica catalog for applications in a set of
data-intensive scientific experiments covered by the following
collaborations: EDG, GriPhyn, PPDG.

The tables in this document are maintained in an Excel spreadsheet and
pasted into this document, which describes the table fields, the
assumptions behind the numbers, and lists open issues that still need to
be resolved.

Requirements are broken down into "performance" (speed), and capacity.

# Architectural and Usage Assumptions

Single logical catalog within an experiment

All file accesses are looked up

Model is that of current Globus catalog

No structure in lfns or collection names

Collections names used to ...

Separate out grid storage from local temporary storage, or
non-replica-managed storage.

Define sites and storage servers as a hierarchy: sites contain one or
more storage server. The replica catalog just catalogs things down to
the site level.

# Capacity Metrics

*Primary Data*: these fields describe the handling of logical file names
and attributes.

*\# Files*: the number of logical file names that can be cataloged

*\# LogicalCollections*: the number of logical collections that can be
managed

*\# Files / LogicalCollection*: the number of files expected per logical
collection. To get some idea of the distribution of files across
collections, we show maximum, average, and mode. By mode, we mean the
most frequently occurring replica count (or "typical" count).

*\# Sites*: the number of sites that the experiment's grid data will be
spread across. A site is a building or campus served by a LAN. Data
transport between sites is over a WAN. Where the distinction gets
blurred, we define a site as a set of nodes between which packet
latencies (on an idle network) are \<= 10 msec, and between sites, \> 10
msec.

*\# Storage Servers*: A storage server is a server addressed by a single
URL prefix - protocol and hostname. A site can have more than one
storage server.

*Replicas / file*: The number of physical copies of each logical file,
characterized as a distribution (as above) with the statistics maximum,
average/, and mode.

*\# Locations*: Since in the Globus replica catalog tracks physical
locations separately for each collection, we track the total number of
locations (summed over all logical collections). For example, if we had
10 collections, and each collection has files at 5 locations, we would
mark the #locations as 50. This is an attempt to capture how many
location objects would need to exist in the catalog.

# Performance Metrics

(note: these goals do not include data copy times, but rather the load
that replica management will need to support on the catalog).

*\# catalog users:* the number of people in the experiment that would be
performing work (batch or interactive computing) that would generate
replica catalog requests.

For the following three statistics, we are trying to capture the peak
rates (busiest minute):

*Insertions (replicas/min):* insertions of new physical or logical files
into the catalog

*Lookups (replicas/min):* lookup requests for physical or logical files

*Deletions (replicas/min):* deletion requests for phyical or logical
files

The following two metrics assume that while the catalog service may
appear to all users as a unified, experiment-wide, single name space
catalog, its implementation may involved multiple catalog servers,
geographically separated, with some type of database replicatin mechanim
that keeps them synchronized. These metrics are measuring the lag time
in this synchronization.

*Latency till Locally visible*: from the addition, deletion, or change
of an entry till its available to all servers at a site.

*Latency till Globally visible*: from the addition, deletion, or change
of an entry till its available to all servers in the grid.

# Open Issues

## Missing Metrics

Show the distribution of computing activity (SPECint95-seconds) per
catalog request.

We might want to show the concurrent number of connections to the
catalog service. For this we might want to look at the distribution of
the number of concurrent threads that perform catalog protocol requests.

Might need to capture file sizes as well, to look a bit beyond those
issues that are purely catalog-driven. This will help translate #events
into #files, if we knew how many events will typically be stored in a
single file.

## Issues

The numbers for the 2 LHC experiments on this list need to be reconciled
with the 2000 MONARC report and the 2001 LHC Computing review.

We should add LIGO, VIRGO, Genomics and ESA to this list, to encompass
all experiments targeted by PPDG, GriPhyN, and EDG.

Numbers for SDSS, BaBar, D0 need more details.

Need to add numbers for Jlab.

Its possible that for CMS and ATLAS we are confusing logical and
physical file requirements.

The number of catalog users listed for many of the experiments is
probably over-counted -- this statistics is not likely to grow at the
same rate as the file counts.

We may need a better (or more realistic) definition of busiest minute.
Might want to look at simulations and discard the top n% busy minutes,
etc, as queuing anomalies...

# References

CMS Replication Requirements -- informal email memo, Koen Holtman, 22
March 2001:

http://www-unix.mcs.anl.gov/\~wilde/replication/Koen.LHC.rcat.Reqs.2001.0322.txt

Getting started with the Globus Replica Catalog:

http://www.globus.org/gsiftp-alpha/replicaGettingStarted.pdf

Globus Replica Catalog API:

http://www-unix.globus.org/api/c/globus_replica_catalog/html/main.html

Globus Replica Management API:

http://www-unix.globus.org/api/c/globus_replica_manager/html/main.html

Monarc Report, 24 March 2000:
<http://monarc.web.cern.ch/MONARC/docs/phase2report/Phase2Report.pdf>

LHC Computing Review 22 Feb 01:

<http://lhc-computing-review-public.web.cern.ch/lhc-computing-review-public/Public/Report_final.PDF>

Jefferson Lab Computing -- Farm and Mass Storage Design Documentation:
http://cc.jlab.org/scicomp/design

Architecture for Replica Management in Grid Computing Environments

Ann Chernevak, March 2001

Presented at GGF1

<http://www.sdsc.edu/GridForum/RemoteData/Papers/ggf1replica.pdf>

ATF Architecture Document: The DataGrid Architecture Version 1, March 7,
2001 Cancio et al.

<http://grid-atf.web.cern.ch/grid-atf/doc/architecture-2001-03-12.pdf>

ATF WP2 Decisions as of April 18, /2001

<http://grid-atf.web.cern.ch/grid-atf/doc/decisions-2001-04-18.html>