Ceph rawスペースの使用状況を理解できません。
7台のサーバーに14台のHDD(14個のOSD)があり、各HDDは3TB〜42 TB合計でrawスペース).
ceph -s
osdmap e4055: 14 osds: 14 up, 14 in
pgmap v8073416: 1920 pgs, 6 pools, 16777 GB data, 4196 kobjects
33702 GB used, 5371 GB / 39074 GB avail
私は4つのブロックデバイスを作成しました、5 TBそれぞれ:
df -h
/dev/rbd1 5.0T 2.7T 2.4T 54% /mnt/part1
/dev/rbd2 5.0T 2.7T 2.4T 53% /mnt/part2
/dev/rbd3 5.0T 2.6T 2.5T 52% /mnt/part3
/dev/rbd4 5.0T 2.9T 2.2T 57% /mnt/part4
dfは、10,9 TBが合計で使用されていることを示し、cephは33702 GBが使用されていることを示しています。2つのコピーがある場合、それは〜22 TBでなければなりませんが、今では33,7 = TB使用-11 TB失敗.
ceph osd pool get archyvas size
size: 2
ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
39074G 5326G 33747G 86.37
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
data 0 0 0 1840G 0
metadata 1 0 0 1840G 0
archyvas 3 4158G 10.64 1840G 1065104
archyvas2 4 4205G 10.76 1840G 1077119
archyvas3 5 3931G 10.06 1840G 1006920
archyvas4 6 4483G 11.47 1840G 1148291
デバイスとOSDをブロックするFS-XFS
考えられる混乱の原因の1つは、GB対GiB/TB対TiB(ベース10 /ベース2)ですが、ここですべての違いを説明することはできません。
Ceph/RBDは、ボリュームに「遅延」してスペースを割り当てようとします。これが、4つの5TBボリュームを作成したにもかかわらず、20ではなく16TBが使用されていると報告されている理由です。注意すべきいくつかの事柄:
RBDでバックアップされたファイルシステム内のファイルを削除すると、ファイルシステムは内部でブロックを空きとしてマークしますが、通常、それらを基本のブロックデバイス(RBD)に「返さない」ようにします。カーネルのRBDバージョンが十分に新しい(3.18以降)場合は、fstrim
を使用して、解放されたブロックをRBDに返すことができるはずです。これらのファイルシステムで他のファイルを作成および削除したのではないでしょうか。
df
で示される正味のデータ使用量を超えるファイルシステムのオーバーヘッドもあります。 「スーパーブロック」やその他のファイルシステム内部のデータ構造に加えて、RBDがデータを割り当てるときの細分性からある程度のオーバーヘッドが予想されます。 RBDは、その一部しか使用されていない場合でも、常に4MBのチャンクを割り当てると思います。
私はセフの専門家ではありませんが、少し推測させてください。
ブロックデバイスは、discard
オプションなしでマウントされません。したがって、書き込みおよび削除したデータはファイルシステム(/mnt/part1
)ですが、一度書き込まれてトリミングされなかったため、基礎となるファイルシステムに残ります。
プールのUSED
を見て、それらを足し合わせると、16777GBが得られます。これは、ceph -s
が表示されます。そして、それを2(2コピー)で乗算すると、33554GBを取得します。これは、使用されているスペースとほぼ同じです。