Skip to end of metadata
Go to start of metadata

Overview of "Manage Replicated Archive" Use Case

Index, Browse, Validate, Retrieve, Mirror, Migrate, and Regulate archival holdings


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Integrated Observatory Operator
References See Persistent Archive Services II components "IRODS persistent archive", "Persistent archive replication service", "Long-term data archive service", "Long-term data archive access", and "Persistent archive index service"
Uses UC.R1.05 Synchronize State Data
UC.R1.08 Persist Streamed Data
Is Used By  
Extends  
Is Extended By  
In Acceptance Scenarios None
Technical Notes This refers to the internal replication of data to repositories under our control.
Lead Team DM
Primary Service Persistent Archive Services Part 2
Version 2.4
UC Priority 3
UC Status Mapped + Ready
UX Exposure ONC

Summary

This information summarizes the Use Case functionality.


Index, Browse, Validate, Retrieve, Mirror, Migrate, and Regulate archival holdings. Perform the basic management activities needed for the archives to reliably perform those functions.

Assumptions

  • A cataloged source archive exists from which content can be replicated.
  • Replication is not necessarily 'en masse'; strategies about what gets replicated where may be determined by applying policy to information resources of particular characteristics.
  • Content (which policy determines replication actions) is characterized by resource type, dataset provider class (OOI or external), intended use, requested quality of service, nature of data set, geographical affinity (archive at east coast), access privileges, owner, known copies and their location, or any other concepts which may be used in policy statements.
  • The Integrated Observatory operator may appreciate many operational factors that affect setting and execution of policy, including nature and capacity of data storage locations. These may be taken into account in performing and adjusting the management steps below.

Initial State

A destination archive exists into which content can be replicated.

Scenario for "Manage Replicated Archive" Use Case

  1. Integrated Observatory Operator defines a replication policy for specified content
    1. Operator defines content selection, archive location (potentially), number of replicas, backup interval and metadata
    2. Technology implementation(s) not visible to the operator interface are oriented to resources and policy creation based on resource attributes
    3. Policies may cascade or be refined at lower levels (marine facility, platform, instrument, etc)
  2. Integrated Observatory Operator plans to replicate content for archiving
    1. Use archive tools to extract a consistent snapshot of persistent resource
    2. Use persistent archive services to replicate the snapshot across distributed storage facilities
    3. Middleware services (CEI, COI, DM) need to replicate large files across distributed storage facilities
  3. <3> Replicated archives may be leveraged to provide rapid access to information
    1. Cache services may use replicated data to provide high speed availability in the physical installations of the CI, subject to OOI policy
  4. Integrated Observatory Operator restores system from backup after failure
    1. System prompts operator with likely plan for restoration
    2. Not all data from backup must be restored in every case; restore process must intelligently select which data to restore from which archives to bring the restored system to the desired state.
    3. Integrated Observatory Operator is able to customize plan to meet restoration needs
  5. Integrated Observatory Operator is notified of completion of restoration process.

Final State

Archive policies are created, archive content is constructed and updated by the system and archived data are accessible as required.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

These policies may usefully be expressed in terms of iRODS policies, but it would be important to abstract archival capabilities making them not iRODS-specific, and look at similar systems.

Possible scenarios:

  • Replication, managed by a technology such as iRODS, could facilitate the transfer from our systems to a National Archive (NARA?)
  • Ability to backup system snapshots and potentially restart on a separate (new) cluster in case of catastrophic failure.
  • Large file (seismic, video, etc) replication

Will supplementary information (vocabularies, associations) be stored with archive data sets? Otherwise, how is context provided.

When a data provider registers or edits a data source/data set, s/he could

  • Select type of data resource
  • Select type of intended use
  • Request a quality of service

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.