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`
|
||||
and `useAllDevices: true` also with `useAllDevices: false`.
|
||||
|
||||
|
||||
### Extracting a monmap
|
||||
|
||||
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
|
||||
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
|
||||
|
@ -466,6 +532,7 @@ contain 2.5" and 3.5" HDDs in different pools.
|
|||
### 2022-09-03
|
||||
|
||||
* Next try starting for migration
|
||||
* Looking deeper into configurations
|
||||
|
||||
### 2022-08-29
|
||||
|
||||
|
|
Loading…
Reference in a new issue