Rook Migration Recommendations

Select the appropriate migration method depending on your deployment type and whether Ceph data must be preserved. For detailed descriptions of each method, see Rook Migration Methods. Prerequisites for each method are listed in Rook Migration Prerequisites.

All migrations will result in some downtime, as all applications and containers that interact with Ceph, including those outside of StarlingX, must be scaled down during the process.

The following section outlines the migration recommendations for various deployment types.

• Use the redeploy migration method if data does not need to be retained for all deployment types. This method wipes the OSDs and deletes all Ceph data but retains the PVCs (empty). Redeploy is the fastest migration option.

  For Standard with dedicated storage configuration, only redeploy is supported, which deletes the Ceph data. During redeploy, storage nodes are reinstalled as worker nodes. Resource allocation is adjusted as follows:

  • Processor 0:

    • Reserves two-thirds of its memory for platform use.

    • Allocates all CPU cores minus one from processor 0 to the platform (compared to storage nodes, which allocated all resources to the platform).

  • Processor 1 (if present):

    • Allocates 1 core and 1 GB of memory to the platform, in addition to what has been reserved to processor 0.

  Although these hosts can now schedule workloads, dedicating them primarily to managing Ceph storage (as before) is recommended.

• If data needs to be retained, use:

  • Export-import migration for an AIO-SX deployment.

  • In-service migration for an AIO-DX, an AIO- DX with Worker nodes, or a Standard with controller storage deployment.

    For guidance on choosing between these methods, see Export-import or In-service migration method to keep the Ceph data.

Export-Import or In-Service Migration Method to Retain the Ceph Data

If Ceph data must be retained, choosing between export-import and in-service migration depends on deployment characteristics, data volume, and available resources.

AIO-SX Deployments

An All-in-One Simplex (AIO-SX) system with only one OSD can only use export-import migration. In-service migration requires a minimum of two OSDs (per Ceph “osd chassis” in ceph osd tree).

Therefore for AIO-SX systems, export-import method is recommended. This method backs up Ceph data to cgts-vg on the active controller, providing recovery options in case of failure.

Handling RBD Snapshots

• If RBD-type snapshots are present, the export-import migration can be performed only by using an additional parameter. This parameter deletes RBD snapshots but preserves any PVC data derived from them. Only the VolumeSnapshots and VolumeSnapshotContents for RBD snapshots are removed.

• CephFS snapshots are preserved during export-import.

• In-service migration retains all snapshot types including both RBD and CephFS.

Data Volume Considerations

Storage and Backup Requirements:

• Export-import stores exported backups (compressed) on the active controller’s root disk, so sufficient free space is required. This makes it more suitable for environments with small or moderate data sizes.

• In-service does not create data backups. Instead, it uses Ceph’s backfill recovery mechanisms, efficiently redistributing data across OSDs (taking advantage of replica size 2 and 3).

Performance Characteristics

• In-service migration is generally faster on clusters with replicas, because it will use your cluster maximum recovery speed to move data around.

• Export-import processes PVC data one at a time for both export and import, which makes it slower for large clusters.

Therefore, for large clusters, especially when available space for backups is limited, the in-service method is usually the better choice, especially if its a multi-node systems using replica 2 or greater.