---
title: RFR Central Management Service (CMS)
slug: rfr-central-management-service-cms
docTags: 
createdAt: 2026-10-15T00:15:41.996Z
---

RFR Central Management Service (CMS) is a centralized management application designed to manage multiple RFR Service instances through REST APIs. 

RFR CMS provides a single management layer from which administrators can perform operations such as: 

- Creating and deleting filesets 
- Viewing fileset status 
- Starting and stopping fileset replication 
- Triggering fileset replication 
- Performing fileset role-switch operations 
- Monitoring replication status 
- Managing access based on user roles 

# RFR CMS deployment model 

The deployment model consists of components deployed across the Kyndryl Data Center and Customer Data Center. 

In the Customer Data Center, RFR CMS communicates with multiple RFR Service instances over the configured CMS-to-RFR Service communication port. The diagram shows port 46443 for this communication.

::Image[]{src="https://api.archbee.com/api/optimize/QU1TIK52ntw5Jsos0uOt5/OLNL8yACNO_HvVB2x80ea_upload.png" size="90" width="739" height="594" isUploading="false" darkWidth="739" darkHeight="594" showCaption="false"}

RFR CMS can provide a centralized management of multiple RFR service instances and their associated replication relationships. 

# RFR CMS installation and deployment requirements 

RFR CMS is packaged as an InstallAnywhere-based installer and must be installed on a supported Red Hat Enterprise Linux (RHEL) server. 

:::hint{type="info"}
RFR CMS is provided as a separate installation package. The RFR CMS installer is not bundled with the RFR Service installer. 
:::

# RFR compatibility 

RFR CMS supports RFR Service version 8.4.38.0 or later. Make sure that the managed RFR Service instances are running on a supported version before configuring the services in RFR CMS. 

# System requirements 

The server in which RFR CMS is installed must meet the following minimum requirements: 

| <font color="#f7f7f7">**Component** </font> | <font color="#f7f7f7">**Requirement** </font> |
| ------------------------------------------- | --------------------------------------------- |
| Operating System                            | Red Hat Enterprise Linux (RHEL) 8.x           |
| CPU                                         | 2 CPU cores                                   |
| Memory                                      | 3.6 GiB                                       |
| RFR Service version                         | 8.4.38.0 or later                             |

**Dedicated server requirement** 

The server hosting RFR CMS is expected to be dedicated to the CMS application. 

:::hint{type="info"}
Do not run other applications or software workloads on the server where RFR CMS is deployed. This helps ensure that sufficient CPU and memory resources remain available for CMS operation. 
:::

The Linux server configuration required for RFR CMS is similar to the configuration used for the RO Site Controller. 

# Role-Based Access Control (RBAC) 

RFR CMS implements **Role-Based Access Control (RBAC)** to control the operations that a user can perform. RFR CMS supports the following predefined users:  

- **Manager** 
- **Monitor** 

The following roles are available: 

- **ADMIN** 
- **VIEWER** 

**User-to-Role Mapping** 

| <font color="#ffffff">**CMS User** </font> | <font color="#ffffff">**Assigned Role** </font> | <font color="#ffffff">**Access Level** </font> |
| ------------------------------------------ | ----------------------------------------------- | ---------------------------------------------- |
| **Manager**                                | ADMIN                                           | Administrative and read access                 |
| **Monitor**                                | VIEWER                                          | Read-only and monitoring access                |

## Manager user 

The **Manager** user is assigned the **ADMIN** role. This role can perform all the supported CMS administrative and monitoring operations, including: 

- Create filesets 
- Modify filesets 
- Delete filesets 
- View fileset information 
- View fileset status 
- Start replication 
- Stop replication 
- Trigger fileset replication 
- Trigger one-time fileset replication 
- Perform fileset role-switch operations 
- Monitor replication status 

In summary, the Manager has both configuration and monitoring privileges. 

## Monitor user 

The **Monitor** user is assigned the **VIEWER** role. The Monitor user is intended for monitoring and read-only operations. 

The Monitor user can: 

- View fileset information 
- View fileset status 
- View replication status 

This user cannot perform configuration-changing operations such as creating or deleting filesets, starting or stopping replication, or performing role-switch operations. 

**REST API Access by Role** 

The following table lists the REST APIs and the minimum role required to invoke each API. 

| <font color="#fefcfc">**HTTP Method** </font> | <font color="#fefcfc">**REST API Endpoint** </font> | <font color="#fefcfc">**Required Role** </font> |
| --------------------------------------------- | --------------------------------------------------- | ----------------------------------------------- |
| POST                                          | /api/v1/users/changepassword                        | VIEWER                                          |
| POST                                          | /api/v1/filesets/create                             | ADMIN                                           |
| PUT                                           | /api/v1/filesets/\{name}                            | ADMIN                                           |
| DELETE                                        | /api/v1/filesets/\{name}                            | ADMIN                                           |
| GET                                           | /api/v1/filesets/\{name}                            | VIEWER                                          |
| GET                                           | /api/v1/filesets                                    | VIEWER                                          |
| POST                                          | /api/v1/filesets/replication/stop                   | ADMIN                                           |
| POST                                          | /api/v1/filesets/replication/start                  | ADMIN                                           |
| GET                                           | /api/v1/filesets/filesetstatus/\{name}              | VIEWER                                          |
| POST                                          | /api/v1/filesets/filesetstatus                      | VIEWER                                          |
| POST                                          | /api/v1/filesets/replicateFileset                   | ADMIN                                           |
| POST                                          | /api/v1/filesets/replicateFilesetOnce               | ADMIN                                           |
| POST                                          | /api/v1/filesets/roleSwitchFileset                  | ADMIN                                           |

# Access summary 

**VIEWER** access is primarily intended for monitoring and retrieving information. The VIEWER role also has access to the password-change API. 

**ADMIN** access includes VIEWER capabilities in addition to administrative operations that modify filesets or control replication. 

# Deployment architecture 

Based on the deployment model shown in the diagram, the architecture can be described as follows: 

1. The client communicates with the RFR environment through the upstream infrastructure. 
2. RFR CMS is deployed in the Customer Data Center. 
3. RFR CMS provides centralized management for multiple RFR Service instances. 
4. CMS communicates with the managed RFR Service instances using REST APIs. 
5. The diagram shows CMS-to-RFR Service communication over port 46443. 
6. Each RFR Service instance participates in the configured replication topology. 
7. Administrators use the CMS APIs to manage file sets and replication operations across the registered RFR Service instances. 

:::hint{type="info"}
Make sure that the required network connectivity and firewall rules are configured between RFR CMS and all RFR Service instances that CMS is expected to manage. 
:::

# RFR CMS installation 

RFR CMS must be installed using the separately provided InstallAnywhere installation package. 

Before starting the installation: 

1. Verify that the server is running a supported RHEL 8.x operating system. 
2. Verify that at least 2 CPU cores are available. 
3. Verify that at least 3.6 GiB of memory is available. 
4. Ensure that no other application workloads are running on the CMS server. 
5. Verify network connectivity between the CMS server and all RFR Service instances that are managed. 
6. Verify that each target RFR Service is running version 8.4.38.0 or later. 
7. Ensure that the required communication port, shown as 46443 in the deployment model, is accessible between CMS and the RFR Service instances. 
