‹ All work
Web,
IBM,
2026
Mirroring Ceph filesystems without the command line
A guided workflow that replaces nine-plus CLI commands across two clusters, so admins can set up filesystem replication in one flow.
Company
IBM
Role
Lead product designer
Team
3 engineers, 1 PM, 1 Product designer, 1 UX Writer
Timeline
10 weeks
Platform
Web
The short version
1 min
Problem
Setting up filesystem replication in IBM Storage Ceph took 9 or more terminal commands across two clusters, and one wrong token or path meant starting over.
What I did
A guided workflow organized around which cluster sends and which receives, with a token handoff between the two admins and one place to monitor every path.
Result
Setup time fell from 24 minutes to under 3, and task success rose from 62% to 98%.
My role
Led the end-to-end UX, from understanding user challenges and defining the workflow to interaction design, prototyping, and collaborating with product and engineering teams through delivery.
Context
IBM Storage Ceph provides highly scalable shared file storage. To protect data against site failures, administrators rely on Ceph Filesystem (CephFS) mirroring to replicate data snapshots from a primary cluster to a remote secondary site.
Cross-cluster file replication in Ceph is highly powerful but locked behind a complex CLI. Enterprise storage administrators had to configure it across two clusters, with bidirectional cluster management, through a fragmented, error-prone process.
9+ terminal commands are required across source and destination cluster to configure filesystem mirroring.
My role
I led the design of this experience as the Lead Product Designer, working with a PM and three engineers. To accelerate ideation, I experimented with AI-assisted design generation in Figma Make, using Carbon MCP connectors alongside the Carbon Design System guidelines.
Research
To understand how these challenges affected users in practice, I reviewed Ceph community troubleshooting forums and discussions with internal Ceph team members who also contribute to the community. The findings revealed recurring points of confusion and systemic issues in the replication setup process.
The research made it clear that the problem wasn’t just the number of commands, but how much users had to remember and manage themselves. The design needed to bring the process together into one guided flow, make responsibilities across both clusters explicit, and catch mistakes before they became harder to resolve.
9+
Terminal commands across two clusters
2
Clusters to coordinate
10+
Levels deep in some filesystem paths
“Today, 9+ terminal commands are required across source and destination cluster to configure filesystem mirroring”
— Senior Technical PM, Ceph & FDF
Role ambiguity
Administrators regularly mixed up which cluster should generate credentials versus which one should import them.
Context switching
The admin must constantly switch host terminal contexts. Executing a source command on the destination terminal breaks the authentication handshakes invisibly.
Knowledge gaps
Internal Ceph team members confirmed that the setup process assumed administrators already understood how mirroring worked internally before they could configure it.
Approach
Mirroring is powerful, but setting it up has never been easy. Ceph filesystem replication operates on a per-filesystem scope, meaning replication is bi-directional at the cluster level but strictly one-way for each individual filesystem. This requires admins to coordinate across two clusters and follow a lengthy sequence of steps.
Workflow. Before designing any screens, I mapped setup across both clusters. Mirroring involves two clusters, often managed by two different admins, so the design had to make the shift (token handoff) between them feel simple, replacing a long CLI sequence. The admin on the remote cluster generates the token, and the admin on the local cluster imports it to connect the two. Around that handoff and complete replication setup, the steps should follow a clear order: enable mirroring, connect the clusters, choose what to replicate, then monitor and maintain. Each step has its own progress, success and error states, so admins always know where they are and what to do next.
Sitemap. I organized everything under File › Mirroring and split it by direction rather than by feature. Each cluster sends data, receives it, or both, so I split the space into Sources and Destinations. That kept each admin focused on their side, and it gave me a clear home for setup, monitoring and day-to-day actions before I started on the screens.
AI exploration and prototyping. To accelerate ideation and explore layout alternatives for the multi-step flows, I experimented with AI-assisted design generation directly within Figma using Figma Make. Using Carbon MCP connectors alongside the Carbon Design System guidelines markdown file, I generated rapid interface concepts aligned with IBM’s design language.
Key design decisions and trade-offs. The core design work focused on reducing memory load, preventing avoidable errors, and making operational state easier to understand through specific architectural choices:
Organize around filesystem roles
Separating Sources and Destinations made it easier to understand whether a filesystem sends or receives data in a given relationship, reflecting the system’s one-way relationship model while allowing a cluster to participate in multiple relationships.
Trade-off
Role-based views add a little navigation overhead, so cross-view search and clear relationship context remain critical.
Select valid paths instead of relying on manual entry.
The path selector surfaces eligible directories, subvolumes, and path depths, allowing multiple paths and their sync intervals to be configured in one flow rather than repeating setup sequentially.
Trade-off
Dynamic path loading requires real-time backend responsiveness; handling loading states and edge cases (like empty directories) required careful error-state design.
Progressive dropdown path builder for deep hierarchies.
Ceph users normally navigate filesystem hierarchies (subvolume groups, subvolumes, and files) using traditional folder tree view, trying to use that tree view or expanded tables for bulk setup caused heavy visual clutter since paths go 10+ levels deep.
Trade-off
Exchanging a traditional folder tree for dynamic dropdowns trades persistent visual mapping for interface scalability across deep paths; requiring careful handling of loading states and empty directories.
Progressive monitoring
Surfaced per-path status, checkpoints, and sync lag directly alongside configuration to make health and failures instantly actionable.
Trade-off
High-density technical data is essential for diagnosis but can clutter an overview. We prioritized top-level health indicators and next actions, pushing deeper diagnostics to drill-down views.
The core design work focused on reducing memory load, preventing avoidable errors, and making operational state easier to understand.
Solution
The work turned Ceph Filesystem mirroring from a collection of technical commands into a guided, end-to-end workflow.
Getting started
Offers easy service configuration and clear prerequisites to help users get started. Options for setting up mirroring or generating tokens are easily discoverable, enabling users to quickly configure mirroring for their cluster.
Enabling mirroring service - Instead of navigating to the Services page and filling out a form to enable mirroring, users can now activate the service with a single click, without switching screens or completing additional steps. The UI sends an API call checking state; it auto-toggles background modules instantly if found disabled.
Cluster mirroring setup
The token bundles destination credentials, allowing admins to select a mirroring user from a dropdown. To complete setup, the admin pastes or uploads the time-sensitive token to the source.
Generating token - On the destination cluster, the admin first generates a token to share with the local cluster. Token bundles the destination details and credentials.
Importing token - On the source cluster, the user imports the received token to create a mirror peer for a source filesystem with a destination filesystem on a remote cluster.
Mirror paths bulk configuration
The CLI adds one path at a time. The wizard lets admins choose multiple paths and set their sync intervals in one flow, so the effort doesn’t grow with every path.
On the source cluster, once the mirroring setup and mirror link with the destination cluster are complete, the user adds the paths to replicate. The new path selector prevents typing errors by loading only valid local directories, subvolumes, and path depths for selection.
Monitoring and actionable statuses
One place shows sync status, snapshots, checkpoints and last sync for every path. In the CLI these live in separate status commands.
Users can view detailed information for each relationship, including the mirrored path, its status leveraging Ceph’s Mirroring Checkpoint architecture, and other relevant details from source and destination cluster. Sync state and checkpoint progress are shown per path, so admins can see what is syncing, what has failed and how far behind a replica is.
Monitoring ongoing sync and historical snapshots in a single view
Real-time sync tracking for destination filesystems
Result
time spent on replication setup, completion time down from 24 minutes to 2.8 minutes
2%
configuration error rate, reduced manual mistakes through guided steps and validation.
95%
reduction in troubleshooting time, faster recovery with real-time status visibility
By transforming a fragmented, dual-cluster script execution into a single, cohesive user experience, the design achieved the following system optimizations:
Simpler setup. Reduces reliance on cluster experts for routine configuration, making setup easier for general IT teams.
Few manual error. Automates key generation and management, reducing the risk of configuration mismatches.
Faster issue detection. Gives users real-time visibility into mirroring health and performance, helping them identify issues earlier and reduce downtime.
What I learned
The goal wasn’t to hide Ceph’s complexity. It was to put that complexity behind an intuitive workflow, so administrators could focus on what they wanted to replicate and whether it was working.
Next project
Redesigning the IBM Storage Ceph Dashboard →
IBM,
Desktop & Tablet,
2026
