OSDの容量を増やしたい

思った以上にMastodonで使用されているコンテンツ領域の使用量が多くなってきており、一部OSDの容量が切迫してきました。デフォルト設定ではOSDの使用率が90%になると、使用量フル状態と見なされ、backfill処理が止まります。

こうなった場合にうまくリバランスしようにもそれが難しくなり、容量管理がままならないというのがCeph使ってて感じる難しいポイントだったりします。

意外と欲しいやり方が見つからない

確かにCephって水平拡張型の分散クラスタであるため、以下の手段に関しては豊富に情報があります。

• ノードの追加
• OSDの追加

今回の場合、ちょっとそれが難しい事情がありまして。

ノード追加の場合、現在Cephノードは1物理ホストに極力1ノードのみ実装するという構成にしており、やむなく1物理ホストに限り2ノード搭載した構成としています。さらに1ノード増やしてしまうとほぼ確実に1物理ホストを停止するとストレージが維持できなくなり、メンテナンス性が大きく下がってしまいます。

OSD追加に関しても難しいところがあり、1つのノードにあまり多くのOSDを載せてしまうと、1ノード障害発生時のOSD障害数が多くなってしまいます。これを回避するにはレプリカの数を増やす必要があるわけですが、そこを考慮してやたらレプリカを増やすと複製処理のオーバーヘッドがデカい上に、容量効率も悪くなります。

そう、つまりは既存OSDを単純に垂直拡張したい！わけですが、そんな情報殆ど転がっておらず・・・・・・今回、ノード追加は一時的に伴うのですが、OSDを拡張ではなく再構築という形で容量を稼いでみることにしました。

完成予想図はこちら。

まずはノード増設

まずは5号機となるノードを追加します。400GB合計で追加する形とし、これをRADOS領域として供出することで、既存の100GB OSDを全て削除しても容量的には既存環境とイーブンになります。

ノード増設に関しては、過去の記事にも記載をしているので本記事では割愛します。

OSD再構築

続いて、既存の100GB領域が組まれているOSDを外して、新たに200GB領域を追加することで容量拡張を図るわけですが、既存OSD上にあるデータはどうするの？など色々な検討事項があります。

全体の流れ

以下の図を参照してください。こんな流れで作業を進めていきます。

大前提として、途中でOSDが無くなるわけですので、それを差し引いて現在のデータを全て保持しうるかの確認が必要になります。ここを謝るとにっちもさっちもいかなくなる悲しい状況になるので気をつけてください。

リプレース対象OSDのデータを逃がす

既存OSDのデータをまずは逃がします。以下のコマンドを使用します。(以降、Cephユーザで実行することを想定します）

$ sudo ceph osd out <osd-id>

osd-idには0から始まる連番が当てはめられます。今回は1号機から4号機に対してリプレース対象のOSDには0,1,2,3が割り当てられています。これを1台ずつ順にoutモードへ移行させます。

outモードに切り替わったら、そのOSDは「使用しない」と位置づけられ、Cephクラスタ上の戦力に数えられなくなります。Kubernetesで言うcordon/evictの操作に似ていると考えてください。既存データは全て異なるOSDへ転送されることになり、その間のクライアントからのIOは閉塞されます。

つまり、1号機から4号機まで一機にこれを実行してしまうと、全てのレプリカが閉塞してしまってデータアクセスできなくなる可能性があります。例えば私の環境ですと、レプリカ数は3で構成しているので、同時実行するとしたら2つまでと言う風にしています。

OSDの停止

OSD一覧の割り当てPG数を確認し、その値が0になっていればそのOSDは停止が可能になります。OSDの停止は各ノードにSSH等でログインした上で、実行する必要があります。

■OSDを停止する
einsで実行
$ sudo systemctl stop ceph-osd@0

zweiで実行
$ sudo systemctl stop ceph-osd@1

dreiで実行
$ sudo systemctl stop ceph-osd@2

vierで実行
$ sudo systemctl stop ceph-osd@3

これで対象OSDのサービスが停止します。

OSDの撤去

まずはOSDの認証キーリングの削除を実行します。

$ sudo ceph auth del osd.<osd-id>

その後、該当OSDをCephクラスタから削除します。

$ sudo ceph osd rm <osd-id>

これでOSDがお亡くなりになります。ceph osd treeの実行で確認が出来ます。

$ sudo ceph osd tree
ID  CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
　　　　　　　　　：
  1   hdd 0.09669         osd.1    DNE        0　　　　　　 ->削除されたOSD
  5   hdd 0.19429         osd.5     up  0.75006 1.00000　　->生きてるOSD
　　　　　　　　　：

仮想ディスクの削除・再作成

仮想ディスクを削除し、作り直します。実は既存仮想ディスクにはLVMのメタデータやファイルシステムなどが組まれており、Ceph側で構成した色々な情報がそのまま残っています。Ceph-Deployで再デプロイメントしたとして、この残存情報がじゃまをすることが分かったので、今回思いきって削除・再作成をすることとしました。

一度削除して確定、再度設定で新規作成して確定と言う手順を踏むと、ディスクが簡単に認識されるので分かりやすいです。

OSDの再作成

OSDをCeph-Deploy用いて再作成します。

■ジャーナルを別途組む場合
$ ceph-deploy osd create --data /dev/sde --journal /dev/sdd eins

■ジャーナル一体型の場合
$ ceph-deploy osd create --data /dev/sdd zwei

OSDのIDは面白いことに既存を踏襲していました。若番で空いてるところからIDを使ってるのかな?という感じでした。

おまけ：使用量をベースにPGをリバランスする

OSDの使用量に偏りがある場合、以下のようなコマンドの実行で対処することが出来そうです。

$ sudo ceph osd reweight-by-utilization

出力結果の例はこんな感じ
moved 54 / 1424 (3.79213%)
avg 237.333
stddev 37.5965 -> 29.374 (expected baseline 14.0633)
min osd.9 with 205 -> 204 pgs (0.863764 -> 0.859551 * mean)
max osd.6 with 309 -> 290 pgs (1.30197 -> 1.22191 * mean)

oload 120
max_change 0.05
max_change_osds 4
average_utilization 0.7003
overload_utilization 0.8403
osd.6 weight 0.9000 -> 0.8500
osd.7 weight 0.8500 -> 0.8000
osd.5 weight 0.7001 -> 0.7501

使用量や、OSDの割り当て状況を踏まえてCrushmapのWeightを変更してくれるようです。変更量は0.05単位としているようなので、大きく変えたい場合は繰り返し実行することにより、ある程度傾斜をかけさせることも可能なようです。

ただ、リバランスすると言うことは、クラスタにそれなりの負荷がかかることにもなりますので、ご利用は計画的に・・