CEPHの未加工スペース使用量


8

ceph rawスペースの使用状況を理解できません。

7台のサーバーに14台のHDD(14個のOSD)があり、各HDDが3TBで、合計で42TBの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

それぞれ5 TBの4つのブロックデバイスを作成しました。

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

回答:


6

考えられる混乱の原因の1つは、GB対GiB / TB対TiB(ベース10 /ベース2)ですが、ここですべての違いを説明することはできません。

Ceph / RBDは、ボリュームに「ゆるやかに」スペースを割り当てようとします。これが、4つの5 TBボリュームを作成したにもかかわらず、20ではなく16 TBが使用されていると報告している理由です。注意すべきいくつかの事柄:

RBDでバックアップされたファイルシステム内のファイルを削除すると、ファイルシステムは内部的にブロックを空きとしてマークしますが、通常、それらを基本のブロックデバイス(RBD)に「返さない」ようにします。カーネルRBDのバージョンが十分に新しい場合(3.18以降)、を使用fstrimして、解放されたブロックをRBDに戻すことができるはずです。これらのファイルシステムで他のファイルを作成および削除したのではないでしょうか。

また、で示されている正味のデータ使用量を超えるファイルシステムのオーバーヘッドもありますdf。「スーパーブロック」やその他のファイルシステム内部のデータ構造に加えて、RBDがデータを割り当てるときの細分性からある程度のオーバーヘッドが予想されます。RBDは、その一部しか使用されていない場合でも、常に4MBのチャンクを割り当てると思います。


そして私はサイモンに同意します。私たちの両方の答えを一緒に考えて、1つを完成させてください。ところで。いまいましい。20時間前の質問ですが、35秒で答えてくれましたか?:D
Fox

回答ありがとうございます。今、私は私の問題がどこにあり、どのようにそれを解決するかを理解しています。
バージズム

可能なオプション:1. Linuxカーネル> 3.18にアップグレードし、破棄オプションでマウントします。(私はカーネル3.19.0-1.el6.elrepo.x86_64でテストしましたが、毎日デッドロックがありました)。2.サイズが5 TB未満のブロックデバイスを再作成します(XFSは圧縮できません)。3. HDDを追加して、OSDを追加します。
バージズム

1
これで問題なく動作することを確認できます。先週末のUbuntu LTS 14.04.3(sudo apt-get install --install-recommends linux-generic-lts-vivid)で、私のCephクライアントマシンのカーネルを3.19にアップグレードし、再起動し、私のrbdボリュームを再マップしてマウントし、各ボリュームでを実行fstrimし、小さな25TBクラスターで450GBをまとめてリカバリしました。アップグレードしたら、discardオプションでrbdボリュームのマウントを開始してください。
ブライアンクライン2015

5

私はセフの専門家ではありませんが、少し推測させてください。

ブロックデバイスはdiscardオプションなしではマウントされません。したがって、書き込んだり削除したりしたデータはファイルシステム(/mnt/part1)には表示されませんが、一度書き込まれてトリミングされなかったため、基礎となるファイルシステムに残ります。

USEDプールを調べてそれらを足し合わせると、16777GBが得られceph -sます。これは表示されているものと同じです。そして、それを2(2コピー)で乗算すると、33554GBが得られます。これは、使用されているスペースとほぼ同じです。


1
私はフォックスの返答に同意します(これは以下の記事と同時に書きました:-)。discardと「トリム」は、未使用のブロックをブロックデバイスに返すために使用できる同じメカニズムに対して基本的に異なる単語です。discardオプションでマウントすると、望ましい効果が得られます。一部の人々fstrimは、ファイルシステムによる継続的な破棄のオーバーヘッドを回避するために定期的に実行することを好みます。これが機能するためには、RBDドライバーがTRIM /破棄をサポートする必要があることに注意してください。すでに述べたように、RBDカーネルドライバーはLinux 3.18以降でこれを行います。tracker.ceph.com/ issues / 190を参照してください。
スレイネン、2015
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.