CEPH - использование свободного пространства

8

Я не могу понять использование сырого пространства ceph.

У меня 14 жестких дисков (14 OSD) на 7 серверах, по 3 ТБ каждый жесткий диск ~ 42 ТБ общего пространства.

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 ТБ каждый:

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 ТБ, ceph показывает, что используется 33702 ГБ. Если у меня есть 2 копии, это должно быть ~ 22 ТБ, но сейчас у меня 33,7 ТБ - пропущено 11 ТБ.

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

virgism
источник

Ответы:

6

Одним из возможных источников путаницы является ГБ против ГиБ / ТБ против ТиБ (база 10 / база 2), но это не может объяснить все различия здесь.

Ceph / RBD попытается «лениво» выделить место для ваших томов. Вот почему, хотя вы создали четыре тома по 5 ТБ, он сообщает об используемых 16 ТБ, а не 20. Но 16 ТБ - это больше, чем сумма «активного» содержимого ваших файловых систем с поддержкой RBD, которое, как вы говорите, составляет всего около 11 ТБ. Несколько вещей на заметку:

Когда вы удаляете файлы в файловых системах, поддерживаемых RBD, файловые системы внутренне помечают блоки как свободные, но обычно не пытаются «вернуть» их на базовое блочное устройство (RBD). Если ваша версия RBD ядра достаточно свежая (3.18 или новее), вы сможете использовать ее fstrimдля возврата освобожденных блоков в RBD. Я подозреваю, что вы создали и удалили другие файлы в этих файловых системах, верно?

Кроме того, есть некоторые накладные расходы на файловую систему, помимо использования данных в сети df. Помимо «суперблоков» и других структур данных внутренних файловых систем, следует ожидать некоторой дополнительной нагрузки от степени детализации, при которой RBD выделяет данные. Я думаю, что RBD всегда будет выделять порции по 4 МБ, даже если используется только часть из них.

sleinen
источник
И я согласен с Саймоном. Угадай, оба наших ответа вместе сделают один полный. Кстати. будь ты проклят. 20-часовой вопрос, а вы опередили меня на 35 секунд? : D
Фокс
Спасибо вам обоим за ответы. Теперь я понимаю, где моя проблема, и как ее решить.
Виргизм
Возможные варианты: 1. обновить ядро ​​Linux до 3.18 и смонтировать с опцией сброса; (Я тестировал с ядром 3.19.0-1.el6.elrepo.x86_64, но каждый день имел взаимоблокировки); 2. Воссоздать блочные устройства размером <5 ТБ (не может сжать XFS). 3. Добавить жесткий диск и создать дополнительные OSD.
виргизм
1
Можно подтвердить, что это работает нормально. На прошлых выходных я обновил ядро ​​моей клиентской машины Ceph до версии 3.19 в Ubuntu LTS 14.04.3 ( sudo apt-get install --install-recommends linux-generic-lts-vivid), перезагрузил, переназначил и подключил мои тома rbd, запустил fstrimкаждый из них и восстановил 450 ГБ в небольшом кластере по 25 ТБ. После обновления убедитесь, что вы начали монтировать тома rbd с помощью этой discardопции.
Брайан Клайн
5

Я не эксперт по ceph, но позвольте мне немного угадать.

Блочные устройства не устанавливаются без discardопции. Таким образом, любые данные, которые вы записываете и удаляете, не отображаются в файловой системе ( /mnt/part1), но, как только они были записаны и не обрезаны, они остаются в базовой файловой системе.

Если вы посмотрите на USEDсвои пулы и сложите их вместе, вы получите 16777 ГБ, что соответствует показанным значениям ceph -s. И если вы умножите это на два (две копии), вы получите 33554 ГБ, что в значительной степени используется пространство.

Лиса
источник
1
Я согласен с ответом Фокса (который был написан одновременно с моим ниже :-). discardи «отделка» - это в основном разные слова для одного и того же механизма, который можно использовать для возврата неиспользуемых блоков на блочное устройство. Монтаж с discardопцией должен иметь желаемый эффект. Некоторые люди предпочитают периодически запускаться, fstrimчтобы избежать накладных расходов на непрерывные сбросы файловой системой. Обратите внимание, что для того, чтобы все это работало, ваш драйвер RBD должен поддерживать TRIM / Discard. Как я уже сказал, драйвер ядра RBD делает это начиная с Linux 3.18 - см. Tracker.ceph.com/issues/190 .
Sleinen