🕌

Ceph のリソース拡張した際に行ったトラブルシューティング

2021/07/01に公開

はじめに

前回は Kubernetes 上の Rook/Ceph に対し、リソース拡張を行いました。
https://zenn.dev/t_ume/articles/369eb7cd9fe970
今回はその際に出会ったトラブルの対応方法を残しておこうと思います。

ログの確認

トラブルシューティングの基本は、Kubernetes を使っているのでコンテナのトラブルシューティングと一緒です。Pending/CrashLoopBack Pod があれば kubectl describekubectl logs で確認が最初でした。

また、今回の Ceph は Rook が構築を補助しているため、デプロイした Operator Pod のログを確認しました。cluster.yaml を使っているならば、rook-ceph-operator-XXXX で起動しています。
-f オプションを付けると追従します

$ kubectl logs rook-ceph-operator-95f44b96c-2bbn9
2021-05-05 06:57:58.308802 I | rookcmd: starting Rook v1.6.1 with arguments '/usr/local/bin/rook ceph operator'
・・・

OSD が追加されない

何度か作り直していると、追加したストレージが利用されているかどうかが分からなくなる場合がありました。特にブロックストレージの場合はファイルシステムとしてマウントしていないので利用したかどうかがわからない・・・
クラスタを起動したけど OSD が追加されない場合は、追加しようとしているストレージに既にデータが存在しているため追加されない可能性があります。
以下のリンクにもある通り、一度ストレージをクリーンアップすると追加される場合がありました。更に Operator に反応がない場合も一度 Operator Pod を再起動することで OSD が追加される場合がありました。時間経過によっては Operator が自動的に追加してくれるのではと思います。

https://rook.io/docs/rook/v1.6/ceph-teardown.html#zapping-devices

# ここは必須
DISK="/dev/sdb"
sgdisk --zap-all $DISK

# 最初の 100M Byte をゼロクリア 
# ちゃんと消したい場合はストレージのサイズに合わせる必要あり
dd if=/dev/zero of="$DISK" bs=1M count=100 oflag=direct,dsync

# ストレージがSSDの場合は、dd の代わりに実行
blkdiscard $DISK

# あったら削除
ls /dev/mapper/ceph-* | xargs -I% -- dmsetup remove %
rm -rf /dev/ceph-*
rm -rf /dev/mapper/ceph--*

POD が起動しない

MON / MGR の POD が起動しない場合がありました。これは以前に構築した際の管理情報が残っている場合でした。管理情報は cluster.yamldataDirHostPath に記載があるパスに格納されています(デフォルトは /var/lib/rook)。各 Node に入って対象ディレクトリ内をすべて削除し、再デプロイすることで事象が解決しました。

CephCluster が削除されない

これも何度か作り直している際に起こった事象です。
デプロイ後に「あ、パラメータ間違えた」と思い、一度クラスタを削除しようとするのですが、待てど暮せど削除されない・・・CephCluter のリソースを確認するのですがデプロイ中の表記が・・・

こちらもドキュメントや github に対処法が載っていました。

https://rook.io/docs/rook/v1.6/ceph-teardown.html#removing-the-cluster-crd-finalizer

https://github.com/rook/rook/issues/4410

kubectl editcephcluster のリソースを開きます。metadata.finalizers 配下に値が残っているのでこちらを消すと CephCluster が削除されるようになりました。

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  annotations:
・・・
  finalizers:
  - cephcluster.ceph.rook.io ★ ここ
・・・

まとめ

Rook が管理面を行ってくれているので、自動的に復旧してくれる場面が多かったので知らぬ間に直っていることが多かったです。
ただし、状態が想定外の場合はこちらで対処必要となりました。
今回はググってどうにかなるレベルでしたが、Ceph 内のトラブルだったりは奥が深そうです・・・

Discussion