Ceph for research computing and HPC

FERPA applies if your institution receives funds made available under a program administered by the US Secretary of Education. The regulations in 34 CFR Part 99 cover any educational agency or institution that meets that test (34 CFR 99.1), so the question is usually answered by your general counsel or registrar, not by the storage team. Once it applies, every system that holds student education records falls inside the design, including research scratch space, home directories and dataset buckets that contain student records. Confirm the scope with your privacy office before you choose a layout, because the answer decides which volumes, pools and buckets need the controls described below. Ask the privacy office to list the record types in scope, such as enrollment, grades or survey responses that identify students.

A contractor can hold education records only as a school official, under conditions set out in 34 CFR 99.31(a)(1)(i)(B). The party must perform a service the institution would otherwise use its own employees for, the institution must keep direct control over how the records are used and maintained, and the party must follow the redisclosure limits in 99.33(a). For a self-hosted Ceph cluster, this usually means the institution owns the hardware, keys and administrator accounts, and any DeployOpen engagement is written so that the institution directs the work. Put these conditions into the contract and the runbook, and record who holds administrative access. Confirm with counsel whether a support contract, remote access or a managed service changes the analysis.

FERPA expects reasonable methods, such as physical or technological access controls, so that school officials see only the education records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)). In Ceph, this is built from separate pools for sensitive data, CephX users with capabilities limited to specific pools or RGW buckets, and CephFS client permissions scoped to particular paths. Separate RGW users and accounts for each research group, with bucket policies, make the boundary visible in the configuration. Record the mapping from roles to pools and paths, then test it with a non-privileged user. Evidence is the role map, the configuration exports and the test results, kept under change control.

FERPA requires the institution to record each request for access to, and each disclosure of, personally identifiable information from education records, along with the parties involved and their legitimate interests, and to keep that record for as long as the records are kept (34 CFR 99.32). Ceph does not produce that register by itself, so the design must add it. Use RGW access logging or audit output for object access, enable CephFS audit logs where your release supports them, and forward cluster and gateway logs to a central store with retention that matches the records. Map each log entry to a named person or service account and a documented legitimate interest. Confirm log formats and retention options for your Ceph release before you commit to a retention period.

An institution must let a parent or eligible student inspect education records within a reasonable period, and no more than 45 days after the request (34 CFR 99.10(b)). The practical effect is that the institution must be able to find every record about one student quickly, across scratch, home directories and dataset buckets. Storage that holds records without an index forces manual searches. Design a catalog or metadata index that maps student identifiers to object keys and file paths, keep it inside the same protected boundary as the data, and test a sample retrieval within the timeline. The index itself contains personal information, so apply the same access controls to it.

COPPA applies to operators that collect personal information from children under 13, including research studies that collect it online. The COPPA Rule in 16 CFR Part 312, amended at 90 FR 16977 on 22 April 2025, requires a written information security program with a designated coordinator and at least annual risk assessments (16 CFR 312.2 and 312.8). Section 312.10 limits retention to what is reasonably necessary for the purpose collected and requires a written retention policy with a deletion timeframe. For storage, this means lifecycle rules on buckets and directories that expire or delete children's data on a schedule, and proof that deletion ran. Whether your studies are covered is a legal question to confirm with counsel and the institutional review board.

Institutions in the Title IV federal student aid programs agree in their Program Participation Agreement to comply with the GLBA Safeguards Rule in 16 CFR Part 314, and the Department of Education examines compliance in annual audits (FSA Electronic Announcement GENERAL-23-09). The rule requires a written information security program, multi-factor authentication for anyone accessing any information system, and FTC notification within 30 days of discovering an event affecting at least 500 consumers (16 CFR 314.4(c)(5) and (j)). For Ceph, aid data should sit in restricted pools with encryption at rest, MFA-protected administrative access, and an incident process that meets the notification clock. Confirm the exact obligations with your compliance office.

DeployOpen prepares the systems, controls and evidence that an institution needs for a compliance assessment, such as role maps, configuration exports, logging setups and test records. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors, the Department of Education's audit process and regulators make those determinations. Scope, deliverables and timelines are agreed in writing before work starts, so ask for the evidence list in the statement of work and confirm with your auditor which artifacts they expect. Any engagement is shaped by your legal and privacy decisions, which remain with your institution.

The cost follows the written scope, and the main drivers are node count, the depth of benchmarking, identity and compliance evidence, and any migration from an existing NAS or Lustre file system. Hardware is usually a separate purchase from services, so ask the quote to separate the two. Services cover design, cephadm deployment, CephFS and RGW configuration, identity integration, testing, documentation and handover. Benchmark scope matters because the Ceph hardware recommendations say to benchmark before buying, since no two clusters are alike. Migration adds data movement and cutover planning, and identity or evidence work adds effort when the institution must show FERPA or GLBA safeguards. Ask for one-time and recurring costs to be listed separately, including support or retainer terms if you want them.

Duration depends on the written scope, so no general timeline applies across institutions. The main factors are the number of nodes, whether hardware has already arrived, how many CephFS file systems and RGW buckets are needed, how many access groups must be mapped, and whether data must be migrated from an existing system. Benchmarking, a review of network design (bonded links across two switches is the usual recommendation), and institutional change windows also affect the schedule. Acceptance testing of failure scenarios, such as losing a host or a switch, takes time that is often underestimated. Ask the partner for a phased plan with dated milestones and named dependencies on your side.

Your team needs to supply decisions and access before design can finish. Define the access model: which groups get CephFS home and scratch space, which projects get RGW buckets, and who approves quota changes. List the data classes, such as student records covered by FERPA, grant-controlled research data, or public datasets, because they determine encryption, retention and audit needs. Name the identity source, for example directory services or an existing single sign-on provider, and confirm how Dashboard login should work. Finally, assign staff: a sponsor, a storage administrator who will own day-to-day operation, a network contact, and someone from security or compliance who can approve controls. Missing decisions in these areas are a common reason for schedule slips.

A capable team can deploy Ceph in-house, since the project is open source and cephadm manages clusters as containers, starting from a single node and adding hosts and services. The harder parts are capacity planning, placement group and failure domain decisions, metadata performance for many small files, identity integration, backup strategy and upgrades. Ask yourself whether the team has someone who can own storage operations over the life of the cluster, handle health warnings and drive replacements, and keep documentation current. Many institutions split the work: internal staff own operations while a partner designs, deploys and hands over. Either way, confirm the skills and time available before deciding.

Upgrades are planned as a documented sequence, starting from the current release, checking the target release's notes and the cephadm upgrade path, then testing on a non-production cluster. The Ceph releases page lists Squid (19.2.x) and Tentacle (20.2.x) as actively maintained releases, and it notes that they receive periodic backports and security fixes. Confirm the end-of-life dates listed on that page against your operating calendar before choosing a target. The plan should cover client compatibility for CephFS mounts and RGW consumers, a rollback decision point, a backup verified before the change, and a maintenance window. Ask the partner to show the test results and the runbook they will use for your cluster.

A useful quote states the scope in specific terms and lists each deliverable with its acceptance criteria. Ask for the node count and hardware assumptions, the benchmark plan, the CephFS and RGW configurations included, the identity integration method, and whether migration is in scope with the data volume covered. Require a clear split between one-time work and recurring support, along with what a retainer covers, such as patching, upgrades and incident response. Ask how changes to scope are priced and approved, what the institution must provide, and which documents you will receive at handover, such as runbooks, architecture diagrams and the configuration record. Check that testing of failure scenarios is included and how results are reported.

Start by identifying which regulations apply to the data. FERPA applies to educational institutions receiving funds from the US Department of Education, and it requires access controls that limit school officials to records they have a legitimate educational interest in. A contractor may receive education records only under specific conditions, including direct institutional control. Where federal student aid applies, the GLBA Safeguards Rule requires multi-factor authentication for anyone accessing information systems. Ask the partner to map these requirements to Ceph controls such as CephFS client authentication, RGW access policies, encryption, and audit logging. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification, so confirm the evidence your auditors expect before scoping the work.