Simplifying cross-cluster file replication

Overview

Product: IBM Storage Ceph - An enterprise, open-source distributed storage platform.

Users: Enterprise Storage Administrators.

Core Challenge: Transform a deeply fragmented, error-prone Command Line Interface (CLI) configuration process,requiring bidirectional cluster management into an intuitive, intent-driven GUI experience.

Impact: Simplified cross-cluster setup, reduced manual token handling and mapping errors, and gave users real-time visibility into replication health and progress.

88%

less time spent

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

Less time spent diagnosing replication failures and faster recovery with real-time status visibility

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.

Problems

01

Complex command line interface-dependent setup

Setting up replication requires storage administrators to manually execute an intricate series of terminal commands across two geographically isolated clusters. This includes creating users with specific permissions on both the source and destination clusters, enabling the background mirroring service, manually starting background daemons, and generating security tokens on one cluster to securely transfer and import them into the other.

02

Costly troubleshooting and silent failures

A missed flag or incorrect path could cause replication setup to fail, with errors buried in background daemon logs rather than surfaced in the interface. Identifying and resolving these issues required time, repeated troubleshooting, and deep Ceph expertise.

Ceph users seeking help with filesystem mirroring across community forums.

9+ terminal commands are required across source and destination cluster to configure filesystem mirroring

Research and insight

Community evidence

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:

01

Role ambiguity

Administrators regularly mixed up which cluster should generate credentials versus which one should import them.

02

Context switching

The admin must constantly switch host terminal contexts. Executing a source command on the destination terminal breaks the authentication handshakes invisibly.

03

Knowledge gaps

Internal Ceph team members confirmed that the setup process assumed administrators already understood how mirroring worked internally before they could configure it.

Design opportunity

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.

Design process

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.

Design principles

To make the experience simpler and more familiar, I grounded the design in five principles.

5 design principles

1. Reusable setup patterns: a modular flow designed to extend to other Ceph services. 2. Ecosystem consistency: IBM Carbon patterns and standard Ceph terminology throughout. 3. Explicit filesystem roles: peers are set up per filesystem, so a cluster can send some filesystems and receive others. Separate Sources and Destinations views make each role clear. 4. Simple path selection: a path picker that handles nested paths without overwhelming the screen. 5. Visible progress: sync status, checkpoints and replication lag show how far behind each replica is.

AI Exploration & 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.

AI exploration using Figma Make using MCP connectors and guidelines markdown files

Refining AI foundations for Handoff

The AI-generated designs provided an impressive foundational direction close to the final product. However, manual refinements were necessary to handle edge cases and constraints. Because AI output couldn't use official Carbon library components in Figma, we manually reconstructed the designs to ensure complete system compliance and a seamless developer handoff.

Designs

The work turned Ceph Filesystem mirroring from a collection of technical commands into a guided, end-to-end workflow.

Fewer steps

Setup that takes 9+ CLI commands across two clusters became 5 guided steps.

1. 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.

2. 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.

3. 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.

Adding mirroring paths

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.

4. 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.

Monitoring replication

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.

Outcome

By transforming a fragmented, dual-cluster script execution into a single, cohesive user experience, the design achieved the following system optimizations:

01

Simpler setup

Reduces reliance on cluster experts for routine configuration, making setup easier for general IT teams.

02

Few manual errors

Automates key generation and management, reducing the risk of configuration mismatches.

03

Faster issue detection

Gives users real-time visibility into mirroring health and performance, helping them identify issues earlier and reduce downtime.

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.