rook: defining the first step
This commit is contained in:
parent
bcc155c1fd
commit
6e69a121de
1 changed files with 67 additions and 0 deletions
|
@ -424,6 +424,7 @@ For migrating, we don't want rook in the first stage to create any
|
||||||
OSDs. So we will replace `useAllNodes: true` with `useAllNodes: false`
|
OSDs. So we will replace `useAllNodes: true` with `useAllNodes: false`
|
||||||
and `useAllDevices: true` also with `useAllDevices: false`.
|
and `useAllDevices: true` also with `useAllDevices: false`.
|
||||||
|
|
||||||
|
|
||||||
### Extracting a monmap
|
### Extracting a monmap
|
||||||
|
|
||||||
To get access to the existing monmap, we can export it from the native
|
To get access to the existing monmap, we can export it from the native
|
||||||
|
@ -459,6 +460,71 @@ In this particular cluster we have 2 pools:
|
||||||
The device class "hdd-big" is specific to this cluster as it used to
|
The device class "hdd-big" is specific to this cluster as it used to
|
||||||
contain 2.5" and 3.5" HDDs in different pools.
|
contain 2.5" and 3.5" HDDs in different pools.
|
||||||
|
|
||||||
|
### [old] Analysing the ceph cluster configuration
|
||||||
|
|
||||||
|
Taking the view from the old cluster, the following items are
|
||||||
|
important for adding new services/nodes:
|
||||||
|
|
||||||
|
* We have a specific fsid that needs to be known
|
||||||
|
* The expectation would be to find that fsid in a configmap/secret in rook
|
||||||
|
* We have a list of running monitors
|
||||||
|
* This is part of the monmap and ceph.conf
|
||||||
|
* ceph.conf is used for finding the initial contact point
|
||||||
|
* Afterwards the information is provided by the monitors
|
||||||
|
* For rook it would be expected to have a configmap/secret listing
|
||||||
|
the current monitors
|
||||||
|
* The native clusters have a "ceph.client.admin.keyring" deployed which
|
||||||
|
allows adding and removing resources.
|
||||||
|
* Rook probably has a secret for keyrings
|
||||||
|
* Maybe multiple depending on how services are organised
|
||||||
|
|
||||||
|
### Analysing the rook configurations
|
||||||
|
|
||||||
|
Taking the opposite view, we can also checkout a running rook cluster
|
||||||
|
|
||||||
|
### Configuring ceph after the operator deployment
|
||||||
|
|
||||||
|
As soon as the operator and the crds have been deployed, we deploy the
|
||||||
|
following
|
||||||
|
[CephCluster](https://rook.io/docs/rook/v1.8/ceph-cluster-crd.html)
|
||||||
|
configuration:
|
||||||
|
|
||||||
|
```
|
||||||
|
apiVersion: ceph.rook.io/v1
|
||||||
|
kind: CephCluster
|
||||||
|
metadata:
|
||||||
|
name: rook-ceph
|
||||||
|
namespace: rook-ceph
|
||||||
|
spec:
|
||||||
|
cephVersion:
|
||||||
|
image: quay.io/ceph/ceph:v14.2.21
|
||||||
|
dataDirHostPath: /var/lib/rook
|
||||||
|
mon:
|
||||||
|
count: 5
|
||||||
|
allowMultiplePerNode: false
|
||||||
|
storage:
|
||||||
|
useAllNodes: false
|
||||||
|
useAllDevices: false
|
||||||
|
onlyApplyOSDPlacement: false
|
||||||
|
mgr:
|
||||||
|
count: 1
|
||||||
|
modules:
|
||||||
|
- name: pg_autoscaler
|
||||||
|
enabled: true
|
||||||
|
network:
|
||||||
|
ipFamily: "IPv6"
|
||||||
|
dualStack: false
|
||||||
|
crashCollector:
|
||||||
|
disable: false
|
||||||
|
# Uncomment daysToRetain to prune ceph crash entries older than the
|
||||||
|
# specified number of days.
|
||||||
|
daysToRetain: 30
|
||||||
|
```
|
||||||
|
|
||||||
|
We wait for the cluster to initialise and stabilise before applying
|
||||||
|
changes. Important to note is that we use the ceph image version
|
||||||
|
v14.2.21, which is the same version as the native cluster.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Changelog
|
## Changelog
|
||||||
|
@ -466,6 +532,7 @@ contain 2.5" and 3.5" HDDs in different pools.
|
||||||
### 2022-09-03
|
### 2022-09-03
|
||||||
|
|
||||||
* Next try starting for migration
|
* Next try starting for migration
|
||||||
|
* Looking deeper into configurations
|
||||||
|
|
||||||
### 2022-08-29
|
### 2022-08-29
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue