uabrc / uabrc/uabrc.github.io

Upcoming: GPFS5 migration completion

Open
#1,060 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

fix: inaccuracy ⚠️ style: article/section 📝 style: news-item 📢 system: cheaha 🖧 system: data-mgmt 🗃️ system: storage 🛢
Dominant language
Python
Stars
24
Forks
15
Avg merge
10d 3h
Merged PRs (30d)
1

Description

What would you like to see added?

Upcoming is a change in how our Cheaha storage system functions. The description below is not comprehensive.

We will need to create a mental model (analogy or similar) and an article describing how GPFS5 works.

Discuss the following

  • Warm tier (GPFS5, active processing)
  • Cool tier (Ceph, temporarily inactive data)
  • How scratch fits in (parallel to the tiers)
  • How data automatically moves between Warm and Cool tier (dehydrate/rehydrate)
  • Benefits of the data movement (easier data management, better performance esp on scratch)
  • Potential drawbacks (latency during rehydration)
  • Automated data aging policy enforcement
    • 30 days on scratch
    • Data will be removed from scratch
  • FAQ
    • How does this affect existing quotas?
    • How does this affect scratch availability?

Relevant email sent to a group of researchers

Our current scratch storage system is part of our GPFS4 storage platform and is end-of-life. The ongoing, intermittent shortages of scratch space are temporary, and our planned solution is to complete the upgrade and data migration from GPFS4 to GPFS5.

To that end, we are allocating our people power to the upgrade and migration, rather than work to provide support for an end-of-life system. The physical hardware and vendor support to increase storage capacity on GPFS4 do not exist. Another way to increase available space is to remove data. We can assist with rapid deletion of scratch data if you tell us what needs to be deleted from your scratch directories.

The next iteration of scratch will be on the new GPFS5 storage platform. With our upcoming rollout of GPFS5, we intend to automate enforcement of storage usage and data aging policies, which will mitigate scratch shortages. Policy and implementation details are TBD, except for those parts we have previously documented and communicated. One way or another, aging data will be automatically removed from active scratch storage on GPFS5.

Additional thoughts that may be helpful:

  • We expect GPFS5 scratch to be more performant than GPFS4.
  • All of the storage devices are SSDs, with caching at the platform level, meaning frequently-accessed data should be faster to retrieve.
  • Scratch is not part of the tiering system of the /data/ partition. Scratch works in parallel with /data/, serving a distinct purpose.
  • /data/ is intended for medium-term storage of permanent research data, regardless of activity.
  • Scratch is intended for short-term storage of ephemeral data being actively processed or analyzed.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the issue description and the quoted researcher email, then identify the confirmed GPFS5, tiering, scratch, data-aging, quota, and availability details. Done means an article with a clear mental model, the listed topic coverage, and an FAQ; policy and implementation details marked TBD need clarification before writing.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, hpc
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.