ROOK Ceph のブロックストレージを検証したメモ

[ROOK](https://rook.io/)は、Kubernetes用のストレージ・オーケストレーターである。この役割は分散ストレージのシステム管理、自己スケーリング、自己修復を担当する。詳しくはオペレーターを利用することで、ストレージ管理者のタスク、デプロイ、ブートストラップ、構成、プロビジョニング、スケーリング、アップグレード、移行、災害復旧、監視、およびリソース管理を自動化する。

ROOKは、複数のストレージを提供するストレージ・オーケストレーターであり、横断的に共通のフレームワークを提供する。ワークロードに必要なストレージプロバイダーを選択して、Kubernetes上で同じように操作できる。ストレージプロバイダーには以下の種類がある。

* Ceph
* EdgeFS
* CockroachDB
* Cassandra
* NFS
* Yugabyte DB

このROOKが、最も効果的に利用できると考えられるのは、オンプレミス環境でのKubernetesクラスタである。つまり、クラウドのKubernetesサービスでは、Kubernetes上のPersistent Volume Claim(PVC)のAPIから、クラウドのストレージサービスと連携して、永続ボリュームがポッドに対して提供される。そのため、クラウドの環境では ROOK の利便性を感じることは無い。しかし、オンプレミス環境では、Kubernetesクラスタ環境にストレージサービスを構築できるため、低コスト、短期間で、クラウド環境と同様なストレージサービス利用できる。

この記事は、ROOK Cephのブロックストレージについて、Vagrant上のアップストリームのKubernetes 1.17.2 で検証した記録である。ROOK Cephは、Kubenretesクラスタ内部に、Kubernetesのコントローラーと連携してダイナミック・プロビジョニングできるソフトウェア定義ストレージシステム(SDS)である。これまでオンプレミスにKubernetesクラスタを配置する場合には、外部のストレージ装置に依存してきたが、ROOK Cephを使うことで、ワーカーノードの内蔵ディスクを利用して、ストレージのクラスタを作ることができる。このことによってハードウェアのインフラコストを抑えることができる。さらに、オペレーターによって、運用を自動化できるため、クラウドのストレージサービスを利用するかのように使用できると期待される。

しかし、良い話だけでは無い。引き換えとして、Kubernetesのバージョンアップなどの影響を受け易くなるなどの課題があるので、導入にあたっては慎重な姿勢が必要である。



## ROOK実行環境の準備

これまで利用してきた学習用 Kubernetes に以下の改造を加えて、ROOKを実行させる。 リソースを大幅に必要とするため、一般的なパソコンのスペックで動作させるのは難しいパラメーターとなってしまった。

* Vagrantfileの編集
  * メモリとCPUの追加
  * ストレージサイズの変更
  * node2をコピーしてnode3を作成　マスターx1,ワーカーx3 へ

* ansible-playbook の hostsファイルの編集
  * hosts へ node3 を追加、証明書パスの変更
  * nodesの変数範囲の追加
  * KubernetesノードのOSをUbuntu18.04へ変更


## 仮想サーバーの起動

複数ノードを起動する点、そして、仮想マシンの内蔵ディスク追加するため、下記のVagrantプラグインをインストールしておく。

~~~
vagrant plugin install vagrant-cachier
vagrant plugin install vagrant-disksize
~~~

KubernetesをVagrantで起動するコードをクローンする。ブランチ 1.17-3nodeに、３ノード構成でメモリとコア数を増やしたバージョンを追加してある。

~~~
git clone -b 1.17-3node https://github.com/takara9/vagrant-kubernetes k8s
cd k8s
~~~

仮想サーバーの起動を以下のコマンドで実行する。

~~~
vagrant up
~~~

起動の確認

~~~
export KUBECONFIG=`pwd`/kubeconfig/config
kubectl get node
NAME     STATUS   ROLES    AGE    VERSION
master   Ready    master   2m5s   v1.17.2
node1    Ready    <none>   92s    v1.17.2
node2    Ready    <none>   93s    v1.17.2
node3    Ready    <none>   93s    v1.17.2
~~~


## 外部アクセスノードの作成

ホントは正しく無いことであるが、masterノードを外部からアクセスするため NodePort 中継ノードにする。
masterノードに付与したホスト側LANのIPアドレスとNodePortのポート番号で、K8sクラスタ外部からアクセスできるようになる。

マスターノードを停止して、IPアドレスを設定して、再び起動する。

~~~
vagrant halt master
~~~

Vagrantfileを編集して、パソコンが繋がるLAN側にIPアドレス設定する。

~~~
vi Vagrantfile 
~~~

15４行目がコメントになっているので、＃を消して有効な行にする。

~~~file:Vagrantfile
    153     machine.vm.network :private_network,ip: "172.16.20.11"
    154     machine.vm.network :public_network, ip: "192.168.1.91", bridge: "en0: Ethernet"
~~~

再び master ノードを起動する。起動過程でインタフェースの選択を要求する場合があるので、ここでは有線LANのインタフェースを洗濯した。

~~~
vagrant up master
Bringing machine 'master' up with 'virtualbox' provider...
==> master: Checking if box 'ubuntu/xenial64' version '20200121.0.0' is up to date...
==> master: Clearing any previously set forwarded ports...
==> master: Fixed port collision for 22 => 2222. Now on port 2202.
==> master: Clearing any previously set network interfaces...
==> master: Specific bridge 'en0: Ethernet' not found. You may be asked to specify
==> master: which network to bridge to.
==> master: Available bridged network interfaces:
1) enp4s0
2) wlp3s0
3) docker0
==> master: When choosing an interface, it is usually the one that is
==> master: being used to connect to the internet.
    master: Which interface should the network bridge to? 1
==> master: Preparing network interfaces based on configuration...
    master: Adapter 1: nat
    master: Adapter 2: hostonly
~~~


## ROOK Ceph のデプロイ

ROOKとCephをインストールする。これによってブロック、ファイル、オブジェクトの３種類のストレージが利用できる。
参考URL ( https://rook.io/docs/rook/v1.2/ceph-quickstart.html )のガイドに従って、インストールを実施する。

~~~
git clone --single-branch --branch release-1.2 https://github.com/rook/rook.git 
cd rook/cluster/examples/kubernetes/ceph
kubectl create -f common.yaml
kubectl create -f operator.yaml
~~~

上記で、ROOKのCephオペレーターまでが起動する。起動の確認としては、以下４つのポッドが起動すれば完了である。

~~~
kubectl get po -n rook-ceph 
NAME                                  READY   STATUS    RESTARTS   AGE
rook-ceph-operator-6d74795f75-lhf65   1/1     Running   0          5m37s
rook-discover-949bg                   1/1     Running   0          4m42s
rook-discover-m5sz7                   1/1     Running   0          4m42s
rook-discover-zrdhd                   1/1     Running   0          4m42s
~~~

ここで、ワーカーノードのOSストレージを利用すると、Cephに圧迫されて、コンテナ用のファイルシステムエリアが不足して、ワーカーノードの正常稼働の障害となるため、ワーカーノードに仮想ディスクを追加して、Cephから利用する。

次のファイルは、CephのCRDを使用してCephを起動するマニフェストである。この中でワーカーノードのディスクをマウントしたパス `/var/lib/rook` にCephのデータを `dataDirHostPath: /var/lib/rook` によって設定する。以下のcluster.yamlは、要点が判る様にコメント文を除いてたもので編集して作成する。

~~~file:cluster.yaml
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: ceph/ceph:v14.2.6
    allowUnsupported: false
  dataDirHostPath: /var/lib/rook  # <---　データディレクトリ
  skipUpgradeChecks: false
  continueUpgradeAfterChecksEvenIfNotHealthy: false
  mon:
    count: 3
    allowMultiplePerNode: false  # モニターはノードに一つ
  dashboard:
    enabled: true
    ssl: true
  monitoring:
    enabled: false
    rulesNamespace: rook-ceph
  network:
    hostNetwork: false　# ポッドネットワークを使用、パフォーマンスを求める時は再考
  rbdMirroring:
    workers: 0
  crashCollector:
    disable: false
  annotations:
  resources:
    mgr:
      limits:
        cpu: "500m"
        memory: "1024Mi"
      requests:
        cpu: "500m"
        memory: "1024Mi"
  removeOSDsIfOutAndSafeToRemove: false
  storage:
    useAllNodes: true
    useAllDevices: true
    config:
      databaseSizeMB: "1024" # uncomment if the disks are smaller than 100 GB
      journalSizeMB: "1024"  # uncomment if the disks are 20 GB or smaller
      osdsPerDevice: "1" # this value can be overridden at the node or device level
    directories:
    - path: /ceph_data
  disruptionManagement:
    managePodBudgets: false
    osdMaintenanceTimeout: 30
    manageMachineDisruptionBudgets: false
    machineDisruptionBudgetNamespace: openshift-machine-api
~~~

ワーカーノードを構築する際に、Ansibleから追加したワーカーノード仮想ディスクをマウントしておく。次のファイル node_storage.yml がマウントするための プレイブックの一部である。

~~~file:node_storage.yml
- hosts: nodes
  become: yes
  gather_facts: True

  tasks:
    - name: include k8s version
      include_vars: /vagrant/ansible-playbook/versions.yml

    - name: mkfs /dev/sdc
      filesystem:
        fstype: ext4
        dev: /dev/sdc

    - name: Creates directory
      file:
        path: /ceph_data
        state: directory
        owner: root
        group: root
        mode: 0775

    - name: mount /ceph_data
      mount:
        path: /ceph_data
        src: /dev/sdc
        fstype: ext4
        state: mounted
~~~

前述で編集したcluter.yamlを適用して、Cephを起動する。

~~~
kubectl create -f cluster.yaml
~~~

起動には、数分を要するので、-w をつけて様子を見ると良い。最終的には以下の状態になる。

~~~
kubectl get po -n rook-ceph 
NAME                                              READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-9vzmd                            3/3     Running     0          9m3s
csi-cephfsplugin-bzjmk                            3/3     Running     0          9m3s
csi-cephfsplugin-provisioner-565ffd64f5-gjbhc     4/4     Running     0          9m3s
csi-cephfsplugin-provisioner-565ffd64f5-tj7h7     4/4     Running     0          9m3s
csi-cephfsplugin-pv5s9                            3/3     Running     0          9m3s
csi-rbdplugin-cws6k                               3/3     Running     0          9m3s
csi-rbdplugin-jpgjb                               3/3     Running     0          9m3s
csi-rbdplugin-p6zxd                               3/3     Running     0          9m3s
csi-rbdplugin-provisioner-7bb78d6c66-p49kw        5/5     Running     0          9m3s
csi-rbdplugin-provisioner-7bb78d6c66-r687q        5/5     Running     0          9m3s
rook-ceph-crashcollector-node1-7bbb758b85-lxnmj   1/1     Running     0          5m46s
rook-ceph-crashcollector-node2-6c58bddcdd-hc7ck   1/1     Running     0          5m28s
rook-ceph-crashcollector-node3-7c8c9dd5bc-9c5h8   1/1     Running     0          4m44s
rook-ceph-mgr-a-98554f488-8zjft                   1/1     Running     0          5m8s
rook-ceph-mon-a-59c478755b-8tk8d                  1/1     Running     0          5m54s
rook-ceph-mon-b-5d9d488947-4r5xh                  1/1     Running     0          5m46s
rook-ceph-mon-c-6bfd478cc5-hkhx2                  1/1     Running     0          5m28s
rook-ceph-operator-6d74795f75-95nnv               1/1     Running     0          23m
rook-ceph-osd-0-644d5c77d7-mqfwd                  1/1     Running     0          4m45s
rook-ceph-osd-1-54964546d4-xfwwh                  1/1     Running     0          4m44s
rook-ceph-osd-2-78b5c5f8b-nss7l                   1/1     Running     0          4m44s
rook-ceph-osd-prepare-node1-jtk75                 0/1     Completed   0          4m49s
rook-ceph-osd-prepare-node2-c5r2n                 0/1     Completed   0          4m49s
rook-ceph-osd-prepare-node3-jzl2w                 0/1     Completed   0          4m49s
rook-discover-dqm9l                               1/1     Running     0          23m
rook-discover-hvgcf                               1/1     Running     0          23m
rook-discover-mvd7s                               1/1     Running     0          23m
~~~


## ツールボックスによるテスト

同じディレクトリ `rook/cluster/examples/kubernetes/ceph` のtoolbox.yamlを利用すると、cephコマンドを実行できる。

~~~
kubectl create -f toolbox.yaml
deployment.apps/rook-ceph-tools created

kubectl -n rook-ceph get pod -l "app=rook-ceph-tools"
NAME                               READY   STATUS    RESTARTS   AGE
rook-ceph-tools-78b599b6dd-47vdt   1/1     Running   0          11s
~~~

ターミナルをポッドに繋いで、対話型でcephコマンドを実行する。

~~~
kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') bash

[root@rook-ceph-tools-78b599b6dd-47vdt /]# ceph status
  cluster:
    id:     40b602cc-b666-458f-b3a5-25287d48d6d4
    health: HEALTH_OK
 
  services:
    mon: 1 daemons, quorum a (age 25m)
    mgr: a(active, since 25m)
    osd: 3 osds: 3 up (since 24m), 3 in (since 24m)
 
  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 B
    usage:   17 GiB used, 129 GiB / 145 GiB avail
    pgs:     
 
[root@rook-ceph-tools-78b599b6dd-47vdt /]# ceph osd status
+----+-------+-------+-------+--------+---------+--------+---------+-----------+
| id |  host |  used | avail | wr ops | wr data | rd ops | rd data |   state   |
+----+-------+-------+-------+--------+---------+--------+---------+-----------+
| 0  | node2 | 5718M | 42.8G |    0   |     0   |    0   |     0   | exists,up |
| 1  | node1 | 5684M | 42.8G |    0   |     0   |    0   |     0   | exists,up |
| 2  | node3 | 5684M | 42.8G |    0   |     0   |    0   |     0   | exists,up |
+----+-------+-------+-------+--------+---------+--------+---------+-----------+

[root@rook-ceph-tools-78b599b6dd-47vdt /]# ceph df
RAW STORAGE:
    CLASS     SIZE        AVAIL       USED       RAW USED     %RAW USED 
    hdd       145 GiB     129 GiB     17 GiB       17 GiB         11.49 
    TOTAL     145 GiB     129 GiB     17 GiB       17 GiB         11.49 
 
POOLS:
    POOL     ID     STORED     OBJECTS     USED     %USED     MAX AVAIL 

[root@rook-ceph-tools-78b599b6dd-47vdt /]# rados df
POOL_NAME USED OBJECTS CLONES COPIES MISSING_ON_PRIMARY UNFOUND DEGRADED RD_OPS RD WR_OPS WR USED COMPR UNDER COMPR 

total_objects    0
total_used       17 GiB
total_avail      129 GiB
total_space      145 GiB
~~~

## Cephの調整

仮想マシンのOSが Ubuntu 16.04 の場合は、カーネルの問題によりペンディングを回避する目的で、パラメータを変更する。一方、Ubuntu 18.04 を利用している場合は不要である。本記事で利用するブランチ 1.17-3node の場合は、Ubuntu 18.04 を使用しているので、以下の調整は不要である。

デフォルトのtunablesパラメータを確認する。以下の様にjewelでは、ブロックストレージが獲得されない課題があるので、変更する。

~~~concole:
[root@rook-ceph-tools-78b599b6dd-8srn5 /]# ceph osd crush show-tunables 
{
    "choose_local_tries": 0,
    "choose_local_fallback_tries": 0,
    "choose_total_tries": 50,
    "chooseleaf_descend_once": 1,
    "chooseleaf_vary_r": 1,
    "chooseleaf_stable": 1,
    "straw_calc_version": 1,
    "allowed_bucket_algs": 54,
    "profile": "jewel",　　 <<--- 設定のプロファイルが jewel になっている
    "optimal_tunables": 1,
    "legacy_tunables": 0,
    "minimum_required_version": "jewel", 
    "require_feature_tunables": 1,
    "require_feature_tunables2": 1,
    "has_v2_rules": 0,
    "require_feature_tunables3": 1,
    "has_v3_rules": 0,
    "has_v4_buckets": 1,
    "require_feature_tunables5": 1,
    "has_v5_rules": 0
}
~~~

hammerに設定を変更しておく。

~~~
[root@rook-ceph-tools-78b599b6dd-8srn5 /]# ceph osd crush tunables hammer
adjusted tunables profile to hammer
~~~

変更を確認する。

~~~
[root@rook-ceph-tools-78b599b6dd-8srn5 /]# ceph osd crush show-tunables 
<中略>
    "profile": "hammer",
<以下省略>
~~~

これで、Cephクラスタ側の設定は完了したので、クライアント側に入っていく。


## ストレージクラスの設定

ダイナミック・プロビジョニングを実行するために、ストレージクラスを設定する。

~~~
cd csi/rbd
kubectl apply -f storageclass.yaml 
cephblockpool.ceph.rook.io/replicapool created
storageclass.storage.k8s.io/rook-ceph-block created
~~~

設定されたことを確認する。

~~~
kubectl get sc
NAME              PROVISIONER                  RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
rook-ceph-block   rook-ceph.rbd.csi.ceph.com   Delete          Immediate           false                  35s
~~~

これで、ブロックストレージを動的にプロビジョニングできるようになった。


## 動作検証 WordPressの起動

次に、ダイナミックプロビジョニングの機能を確かめるテストを実施する。テストには Wordpress　を起動して、コンテンツとデータベースの二つの永続データの領域が ROOK Ceph から確保されるようにする。

サンプルのマニフェストが存在するディレクトリへ移動する。

~~~
$ cd ../../..
~~~

データベースをデプロイする。

~~~
kubectl apply -f mysql.yaml 
~~~

アプリケーションサーバーをデプロイする。

~~~
kubectl apply -f wordpress.yaml 
~~~

これにより、PVCが二つ作成される。

~~~
kubectl get pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mysql-pv-claim   Bound    pvc-4af72998-cfcf-46a7-9fe4-624e34db85cd   20Gi       RWO            rook-ceph-block   11s
wp-pv-claim      Bound    pvc-2c7a1991-00dd-4309-9883-c9c69eb0e7db   20Gi       RWO            rook-ceph-block   5s
~~~


## Persistent Volume Claim

ここで、マニフェストを確認しておく。PVCのマニフェストでは、ブロックストレージなので、accessModesは共有を許さない ReadWriteOnceとなっている。

~~~file:wordpress.yaml抜粋
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pv-claim
  labels:
    app: wordpress
spec:
  storageClassName: rook-ceph-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
~~~

ブロックストレージをファイルシステムにマウントできる。つまり、おそらくプロビジョナーが動的にファイルシステムを作成してくれている。

~~~file:wordpress.yaml抜粋
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
~~~


## トラブルシューティング

前述の`ceph osd crush tunables hammer`を実行しなかった場合の問題について、説明する。

次のように、ポッドがポッドが'ContainerCreating'の状態のまま、次の段階に進まない場合、Cephに原因があるケースがある。

~~~
kubectl get po
NAME                              READY   STATUS              RESTARTS   AGE
wordpress-5b886cf59b-6mdnv        0/1     ContainerCreating   0          2m44s
wordpress-mysql-b9ddd6d4c-s7dfc   0/1     ContainerCreating   0          2m50s
~~~

このようなケースの場合、ポッドの詳細を表示して Eventsを確認することで、停滞の原因が判る。ボリュームがマウントできない、タイムアウトのエラーが発生してることが判る。つまり、CephやROOKに問題があることが推定される。

~~~
kubectl describe po wordpress-mysql-b9ddd6d4c-s7dfc

<中略>

Events:
  Type     Reason                  Age                  From                     Message
  ----     ------                  ----                 ----                     -------
  Warning  FailedScheduling        3m9s (x2 over 3m9s)  default-scheduler        error while running "VolumeBinding" filter plugin for pod "wordpress-mysql-b9ddd6d4c-s7dfc": pod has unbound immediate PersistentVolumeClaims
  Normal   Scheduled               3m8s                 default-scheduler        Successfully assigned default/wordpress-mysql-b9ddd6d4c-s7dfc to node1
  Normal   SuccessfulAttachVolume  3m8s                 attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-4af72998-cfcf-46a7-9fe4-624e34db85cd"
  Warning  FailedMount             65s                  kubelet, node1           Unable to attach or mount volumes: unmounted volumes=[mysql-persistent-storage], unattached volumes=[mysql-persistent-storage default-token-8qr52]: timed out waiting for the condition
  Warning  FailedMount             58s (x2 over 119s)   kubelet, node1           MountVolume.MountDevice failed for volume "pvc-4af72998-cfcf-46a7-9fe4-624e34db85cd" : rpc error: code = Internal desc = rbd: map failed exit status 110, rbd output: rbd: sysfs write failed
In some cases useful info is found in syslog - try "dmesg | tail".
rbd: map failed: (110) Connection timed out
~~~

このケースは、https://github.com/ceph/ceph-helm/issues/60 によると、以下の原因にあたる。

>  Important Kubernetes uses the RBD kernel module to map RBDs to hosts. Luminous requires CRUSH_TUNABLES 5 (Jewel). The minimal kernel version for these tunables is 4.5. If your kernel does not support these tunables, run ceph osd crush tunables hammer

Ubuntu 16.04 を使用したワーカノードのカーネルのバージョンを調べると、4.4である。つまり、上記に該当するため、変更が必要となる。

~~~
vagrant@node1:~$ uname -a
Linux node1 4.4.0-171-generic #200-Ubuntu SMP Tue Dec 3 11:04:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
~~~


Ubuntu 18.04 を使用したカーネルは以下の通りであるので、対応は不要となる。

~~~
vagrant ssh node3
Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-76-generic x86_64)
~~~



## ROOK Ceph ダッシュボード

ブラウザからCephのダッシュボードを参照できるように設定を変更する。

初期設定では、サービスタイプが、ClusterIPになっている。これではクラスタ外部からアクセスすることができない。

~~~
kubectl -n rook-ceph get service rook-ceph-mgr-dashboard 
NAME                       TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)             AGE
rook-ceph-mgr-dashboard    ClusterIP   10.32.0.200   <none>        8443:31930/TCP      5h49m
~~~

サブコマンド edit を使って、実行中のマニフェストを変更して、K8sクラスタ外部からアクセスできるように変更する。

~~~
kubectl -n rook-ceph edit service rook-ceph-mgr-dashboard
~~~

次は、上記のコマンドの実行結果である。35行目の `type: ClusterIP` を `type: NodePort` を変更する。

~~~
     23 spec:
     24   clusterIP: 10.32.0.252
     25   ports:
     26   - name: https-dashboard
     27     port: 8443
     28     protocol: TCP
     29     targetPort: 8443
     30     nodePort: 30443
     31   selector:
     32     app: rook-ceph-mgr
     33     rook_cluster: rook-ceph
     34   sessionAffinity: None
     35   type: ClusterIP
~~~

上記の変更によって、以下のように、ノードのポートが開かれ、Cephのダッシュボードへアクセスが可能となる。マニフェストのports: に `nodePort: 30443` を加えて設定することで、ポートが空いていれば、ダッシュボードのアドレスを一定に維持できる。

~~~
kubectl get svc -n rook-ceph rook-ceph-mgr-dashboard
NAME                      TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
rook-ceph-mgr-dashboard   NodePort   10.32.0.252   <none>        8443:30443/TCP   17h
~~~



Cephダッシュボードにアクセスするには、パスワードが必要となる。このパスワードの取得は次のコマンドを実行することで得られる。

~~~
kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode && echo
xZVbe1aVOL
~~~

マスターノードの仮想マシンホストに追加したIPアドレスに、このポート番号を追加して、https://192.168.1.91:30443 として ユーザーID admin でアクセスできる。

![Ceph-Dashbd.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42829/6c7b5732-d41d-3aa0-775e-41967894d4e1.png)


## まとめ

ROOKでは、Cephを同じKubernetesクラスタ内のワーカーノードの内蔵ディスクを使用してSDSを構築することができる。ワーカーノードに永続データを保存することに、クラスタリングによって分散と冗長性が確保され、データの保全性が高いと言っても、やはり、抵抗感がある。単純なものほど壊れない、その事から、大切なデータを保存する装置は、必要な用件を満たした単純な装置である方が良い。こうすることで、ソフトウェアの複雑な連携、脆弱性、バージョンアップなど、ソフトウェアの不安定さから来る課題から、大切なデータを保護しておける。

しかし、Kubernetesクラスタに加えて、SDSクラスタを構築するとなると、相応のコストが必要となる。しかし、ROOKで同一Kubernetesクラスタに永続データを保持することができれば、手間もコストも少なくて済む。そして、スナップショットを取得してリモートのオブジェクトストレージに保存なども検証してみたい。

今回は、ROOK Cephのセットアップは、非常に簡単で早く実施できることが解った。しかし、Cephについての知識が不要なわけでは無い。ROOKの前にCephを知っているべきとも言える。そして、最新バージョンのCephを利用するには、ワーカーノードのLinuxカーネルのバージョンは4.5以上である必要がある。それが出来ない場合は、プロファイルのレベルを落とす必要がある。

ROOKは、OpenShiftでは OpenShift Container Storage として、OpenShift 4.3から利用できるようになっている。　オンプレミスでOpenShiftを使用する場合には、必要不可欠なコンポーネントになると考えられる。