リバランス時の負荷を簡単に探ってみる
Ceph Luminousに触れていたころから知ってる特性なのですが、OSDを追加すると基本的にリバランス処理が発生します。この間、結構な処理が流れます。
[ceph@eins deploy-cluster]$ sudo ceph -s
cluster:
id: 817a315d-ffe2-4856-b5eb-e5d0904df2b7
health: HEALTH_WARN
934/31986 objects misplaced (2.920%)
Degraded data redundancy: 18056/31986 objects degraded (56.450%), 69 pgs degraded, 44 pgs undersized
services:
mon: 2 daemons, quorum eins,zwei
mgr: eins(active)
mds: dev-cephfs-1-1/1/1 up {0=vier=up:active}, 1 up:standby
osd: 8 osds: 8 up, 8 in; 52 remapped pgs
rgw: 1 daemon active
data:
pools: 8 pools, 288 pgs
objects: 10.66 k objects, 40 GiB
usage: 188 GiB used, 1004 GiB / 1.2 TiB avail
pgs: 18056/31986 objects degraded (56.450%)
934/31986 objects misplaced (2.920%)
203 active+clean
38 active+recovery_wait+undersized+degraded+remapped
27 active+recovery_wait+degraded
9 active+remapped+backfill_wait
4 active+recovery_wait+undersized+degraded
4 active+recovery_wait
2 active+recovering+undersized+remapped
1 active+recovering
io:
recovery: 24 MiB/s, 6 objects/s
上記のように、CRUSHアルゴリズムに従い、本来配置すべきオブジェクト位置を定めて再配置が行われます。基本的にそのIOをやり取りすることは可能です。注意すべきは「pgs」のところで、「activating」と言う表示が出ていた場合で、このときそのPGに対するアクセスは行えません。
そのため、アクセスできない箇所に対するところでIO処理が停滞すると、場合によってはデッドロックにもなったりするので、二次障害が波及しないようそれなりの配慮が必要になる点は本当に気をつけてください。
ネットワークグラフを覗いてみる
各ホストのネットワークトラフィックを覗いてみる。
意外とグラフが乱高下していて安定性に欠けるなぁと感じています。ただ、リカバリープロセスに対する帯域は24MB/sec程度に保たれているので、これはこれでまだ現実的な動きが出来てるのかなぁと感じました。
以前Luminousを使ってたときはもっと高速だったように思いますが、当時はかなりカリカリにチューニングしていて、しかもそれを今覚えてないと言うね・・・。
少しずつ思い出しながらきれいなチューニングを心掛けてみたいと思います。
ディスクグラフを覗いてみる
ディスクのスループット状況も、ネットワークのインターコネクトと同様の形状になりました。ただ、意外とディスクスループットは出てるようで、単にディスク処理の量が多いだけみたいに見えます。
ダッシュボード機能もあるよ
CephにはGUIで見やすく状態を確認できるダッシュボードがあります。
MGRノード経由でアクセスすることになりますが、詳細手順は割愛します。有効化の手順が必要です。
各OSDのIO状態を確認することも出来ます。
他にも色々出来るので試してみようズ
RBDでアクセスできる仕組みを作るのは以前もやっていたのですが、今やってみたいこととしては、RADOSGWでAWS S3互換のオブジェクトストレージとして利用する局面を試してみたいなーと思っていたりはしています。
うまくいけばもっと汎用的に様々な活用が出来そうなので。そうしたところをうまくやり取りしながら遊んでいこうと考えています。
using WordPress and
Comments are closed