Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly Container Cloud). This means everything you need is in one place. Some legacy names may remain in the code and documentation and will be updated in future releases. The separate Container Cloud documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Add, remove, or reconfigure Ceph OSDs with metadata devices¶

Warning

This procedure is valid for MOSK clusters that use the MiraCeph custom resource (CR), which is available since MOSK 25.2 to replace the deprecated KaaSCephCluster. For the equivalent procedure with the KaaSCephCluster CR, refer to the following section:

Add, remove, or reconfigure Ceph OSDs with metadata devices

Mirantis Ceph Controller simplifies Ceph cluster management by automating LCM operations. This section describes how to add, remove, or reconfigure Ceph OSDs with a separate metadata device.

Add a Ceph OSD with a metadata device¶

From the Ceph disks defined in the BareMetalHostProfile object that was configured using the Configure Ceph disks in a host profile procedure, select one disk for data and one logical volume for metadata of a Ceph OSD to be added to the Ceph cluster.

Note

If you add a new disk after machine provisioning, manually prepare the required machine devices using Logical Volume Manager (LVM) 2 on the existing node because BareMetalHostProfile does not support in-place changes.
To add a Ceph OSD to an existing or hot-plugged raw device
If you want to add a Ceph OSD on top of a raw device that already exists on a node or is hot-plugged, add the required device using the following guidelines:
- You can add a raw device to a node during node deployment.
- If a node supports adding devices without node reboot, you can hot plug a raw device to a node.
- If a node does not support adding devices without node reboot, you can hot plug a raw device during node shutdown. In this case, complete the following steps:
  1. Enable maintenance mode on the MOSK cluster.
  2. Turn off the required node.
  3. Attach the required raw device to the node.
  4. Turn on the required node.
  5. Disable maintenance mode on the MOSK cluster.

Open the MiraCeph object for editing:

kubectl -n ceph-lcm-mirantis edit miraceph

In the nodes.<nodeName>.devices section, specify the parameters for a Ceph OSD as required. For the parameters description, see Node parameters.

The example configuration of the nodes section with the new node:

nodes:
- name: kaas-node-6c5e76f9-c2d2-4b1a-b047-3c299913a4bf
  roles:
  - mon
  - mgr
  devices:
  - config: # existing item
      deviceClass: hdd
    fullPath: /dev/disk/by-id/scsi-SATA_HGST_HUS724040AL_PN1334PEHN18ZS
  - config: # new item
      deviceClass: hdd
      metadataDevice: /dev/bluedb/meta_1
    fullPath: /dev/disk/by-id/scsi-0ATA_HGST_HUS724040AL_PN1334PEHN1VBC

Warning

Mirantis highly recommends using the non-wwn by-id symlinks to specify storage devices in the devices list.

For details, see Addressing storage devices since MOSK 25.2.

Verify that the Ceph OSD is successfully deployed on the specified node:

kubectl -n ceph-lcm-mirantis get mchealth -o yaml

In the system response, the fullClusterInfo section should not contain any issues.

Example of a successful system response:

status:
  fullClusterInfo:
    daemonsStatus:
      ...
      osd:
        running: '4/4 running: 4 up, 4 in'
        status: Ok

Verify the Ceph OSD status:

kubectl -n rook-ceph get pod -l app=rook-ceph-osd -o wide | grep <nodeName>

Substitute <nodeName> with the corresponding node name.

Example of system response:

rook-ceph-osd-0-7b8d4d58db-f6czn   1/1     Running   0          42h   10.100.91.6   kaas-node-6c5e76f9-c2d2-4b1a-b047-3c299913a4bf   <none>           <none>
rook-ceph-osd-1-78fbc47dc5-px9n2   1/1     Running   0          21h   10.100.91.6   kaas-node-6c5e76f9-c2d2-4b1a-b047-3c299913a4bf   <none>           <none>
rook-ceph-osd-3-647f8d6c69-87gxt   1/1     Running   0          21h   10.100.91.6   kaas-node-6c5e76f9-c2d2-4b1a-b047-3c299913a4bf   <none>           <none>

Remove a Ceph OSD with a metadata device¶

Note

Ceph OSD removal implies the usage of the CephOsdRemoveRequest custom resource (CR). For workflow overview, spec and phases description, see High-level workflow of Ceph OSD or node removal.

Warning

When using the non-recommended Ceph pools replicated.size of less than 3, Ceph OSD removal cannot be performed. The minimal replica size equals a rounded up half of the specified replicated.size.

For example, if replicated.size is 2, the minimal replica size is 1, and if replicated.size is 3, then the minimal replica size is 2. The replica size of 1 allows Ceph having PGs with only one Ceph OSD in the acting state, which may cause a PG_TOO_DEGRADED health warning that blocks Ceph OSD removal. Mirantis recommends setting replicated.size to 3 for each Ceph pool.

Open the MiraCeph object of the MOSK cluster for editing:
```
kubectl -n ceph-lcm-mirantis get miraceph
```

Remove the required Ceph OSD specification from the spec.nodes.<nodeName>.devices list:

The example configuration of the nodes section with the new node:

nodes:
- name: kaas-node-5bgk6
  roles:
  - mon
  - mgr
  storageDevices:
  - config:
      deviceClass: hdd
    fullPath: /dev/disk/by-id/scsi-SATA_HGST_HUS724040AL_PN1334PEHN18ZS
  - config: # remove the entire item entry from devices list
      deviceClass: hdd
      metadataDevice: /dev/bluedb/meta_1
    fullPath: /dev/disk/by-id/scsi-0ATA_HGST_HUS724040AL_PN1334PEHN1VBC

Create a YAML template for the CephOsdRemoveRequest CR. For example:
```
apiVersion: lcm.mirantis.com/v1alpha1
kind: CephOsdRemoveRequest
metadata:
  name: remove-osd-<nodeName>-sdb
  namespace: ceph-lcm-mirantis
spec:
  nodes:
    <nodeName>:
      cleanupByDevice:
      - name: sdb
```
Warning

Since MOSK 23.3, Mirantis does not recommend setting device name or device by-path symlink in the cleanupByDevice field as these identifiers are not persistent and can change at node boot. Remove Ceph OSDs with by-id symlinks specified in the path field or use cleanupByOsdId instead. For details, see Addressing storage devices since MOSK 25.2.
Note
- If a device was physically removed from a node, cleanupByDevice is not supported . Therefore, use cleanupByOsdId instead. For details, see Remove a failed Ceph OSD by Ceph OSD ID.
- If the devices item was specified with a by-path device path, specify the path parameter in the cleanupByDevice section instead of name.

Apply the template on the MOSK cluster:

kubectl apply -f remove-osd-<machineName>-sdb.yaml

Verify that the corresponding request has been created:

kubectl -n ceph-lcm-mirantis get cephosdremoverequest remove-osd-<nodeName>-sdb

Verify that the removeInfo section appeared in the CephOsdRemoveRequest CR status:

kubectl -n ceph-lcm-mirantis get cephosdremoverequest remove-osd-<nodeName>-sdb -o yaml

Example of system response:

status:
  removeInfo:
    cleanUpMap:
      kaas-node-d4aac64d-1721-446c-b7df-e351c3025591:
        osdMapping:
          "10":
            deviceMapping:
              sdb:
                path: "/dev/disk/by-path/pci-0000:00:1t.9"
                partition: "/dev/ceph-b-vg_sdb/osd-block-b-lv_sdb"
                type: "block"
                class: "hdd"
                zapDisk: true
          "5":
            deviceMapping:
              /dev/sdc:
                deviceClass: hdd
                devicePath: /dev/disk/by-path/pci-0000:00:0f.0
                devicePurpose: block
                usedPartition: /dev/ceph-2d11bf90-e5be-4655-820c-fb4bdf7dda63/osd-block-e41ce9a8-4925-4d52-aae4-e45167cfcf5c
                zapDisk: true
              /dev/sdf:
                deviceClass: hdd
                devicePath: /dev/disk/by-path/pci-0000:00:12.0
                devicePurpose: db
                usedPartition: /dev/bluedb/meta_1

Verify that the cleanUpMap section matches the required removal and wait for the ApproveWaiting phase to appear in status:
```
kubectl -n ceph-lcm-mirantis get cephosdremoverequest remove-osd-<nodeName>-sdb -o yaml
```
Example of system response:
```
status:
  phase: ApproveWaiting
```

In the CephOsdRemoveRequest CR, set the approve flag to true:

kubectl -n ceph-lcm-mirantis edit cephosdremoverequest remove-osd-<nodeName>-sdb

Configuration snippet:

spec:
  approve: true

Review the following status fields of the Ceph LCM CR request processing:
- status.phase - current state of request processing
- status.messages - description of the current phase
- status.conditions - full history of request processing before the current phase
- status.removeInfo.issues and status.removeInfo.warnings - error and warning messages occurred during request processing, if any
Verify that the CephOsdRemoveRequest has been completed.

Example of the positive status.phase field:
```
status:
  phase: Completed # or CompletedWithWarnings if there are non-critical issues
```

Remove the device cleanup jobs:

kubectl delete jobs -n ceph-lcm-mirantis -l app=miraceph-cleanup-disks

Reconfigure a partition of a Ceph OSD metadata device¶

There is no hot reconfiguration procedure for existing Ceph OSDs. To reconfigure an existing Ceph node, remove and re-add a Ceph OSD with a metadata device using the following options:

If metadata device partitions are specified in the BareMetalHostProfile object as described in Configure Ceph disks in a host profile, the metadata device definition is an LVM path in metadataDevice of the MiraCeph object.

Therefore, automated LCM will clean up the logical volume without removal and it can be reused. For this reason, to reconfigure a partition of a Ceph OSD metadata device:

Remove a Ceph OSD from the Ceph cluster as described in Remove a Ceph OSD with a metadata device.
Add the same Ceph OSD but with a modified configuration as described in Add a Ceph OSD with a metadata device.