Подтвердить что ты не робот

Ceph слишком много pgs за osd: все, что вам нужно знать

Я получаю обе эти ошибки одновременно. Я не могу уменьшить количество pg, и я не могу добавить больше памяти.

Это новый кластер, и я получил это предупреждение, когда я загрузил около 40 ГБ. Думаю, потому что radosgw создал пучок пулов.

Как может у ceph слишком много pgs за osd, но у вас больше объекта на pg, чем в среднем, при слишком небольшом предложении pgs?

HEALTH_WARN too many PGs per OSD (352 > max 300); 
pool default.rgw.buckets.data has many more objects per pg than average (too few pgs?)

osds: 4 (2 per site 500GB per osd)
size: 2 (cross site replication)
pg:  64
pgp: 64
pools: 11

Используя rbd и radosgw, ничего необычного.

4b9b3361

ОТВЕТЫ

Ответ 1

Я собираюсь ответить на свой собственный вопрос в надежде, что он проливает свет на проблему или подобные неправильные представления о внутренних функциях Ceph.

Устанавливает HEALTH_WARN слишком много PG для OSD (352 > max 300) раз и навсегда

При балансировании групп размещения вы должны учитывать:

Нам нужны данные

  • pgs per osd
  • pgs для пула
  • пулы в osd
  • карта сокрушения
  • разумные значения по умолчанию pg и pgp num
  • количество копий

Я буду использовать мою настройку в качестве примера, и вы сможете использовать ее в качестве шаблона для своих собственных.

У нас есть

  • num osds: 4
  • num sites: 2
  • pgs per osd:
  • pgs для пула:
  • количество пулов за osd: 10
  • разумные значения по умолчанию pg и pgp num: 64 (... или это?)
  • количество реплик: 2 (репликация через сайт)
  • карта сокрушения

ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY root ourcompnay site a rack a-esx.0 host prdceph-strg01 osd.0 up 1.00000 1.00000 osd.1 up 1.00000 1.00000 site b rack a-esx.0 host prdceph-strg02 osd.2 up 1.00000 1.00000 osd.3 up 1.00000 1.00000

Наша цель - заполнить '???' выше тем, что нам нужно для обслуживания кластера HEALTH OK. Наши пулы создаются шлюзом rados, когда он инициализируется. У нас есть один default.rgw.buckets.data, где хранятся все данные, остальные пулы являются административными и внутренними для метаданных и бухгалтерского учета.

PGs за osd (какой разумный вариант по умолчанию?)

В документации мы будем использовать этот расчет, чтобы определить наш счетчик pg за osd:

 (osd * 100)
----------- = pgs UP to nearest power of 2
 replica count

Утверждается, что округление оптимально. Таким образом, с нашей текущей настройкой это будет:

 (4 * 100)
----------- = (200 to the nearest power of 2) 256
    2
  • osd.1 ~ = 256
  • osd.2 ~ = 256
  • osd.3 ~ = 256
  • osd.4 ~ = 256

Это рекомендуемое max количество pgs за osd. Итак... что у вас на самом деле сейчас? И почему это не работает? И если вы установите "разумный дефолт" и понять выше. ПОЧЕМУ НЕ ЭТО РАБОТАЕТ!!! >= [

Вероятно, несколько причин. Мы должны понять, что означают эти "разумные дефолты" выше, как их применяют и где. Из вышеизложенного можно неправильно понять, что я мог бы создать новый пул, например:

ceph osd pool create <pool> 256 256

или я мог бы даже подумать, что могу безопасно играть и следовать документации, в которой говорится, что (128 pgs for < 5 osds) может использовать:

ceph osd pool create <pool> 128 128

Это неправильно, плоский. Потому что это никоим образом не объясняет отношения или баланс между тем, что ceph actaully делает с этими числами Технически правильный ответ:

ceph osd pool create <pool> 32 32

И позвольте мне объяснить, почему:

Если вы, как я, вы предоставили кластер с этими "разумными значениями по умолчанию" (128 pgs for < 5 osds), как только вы попытались сделать что-либо с помощью радиостанций, он создал целую пучку пулов и ваш кластер разразился. Причина в том, что я неправильно понял взаимосвязь между всем, что было упомянуто выше.

  • пулы: 10 (создаются с помощью рада)
  • pgs для пула: 128 (рекомендуется в документах)
  • osds: 4 (2 на сайт)

10 * 128 / 4 = 320 pgs per osd

Этот ~320 может быть числом pgs per osd в моем кластере. Но ceph может распространять их по-разному. Это именно то, что происходит и является способом более 256 max за osd, указанным выше. Мой кластер HEALTH WARN равен HEALTH_WARN too many PGs per OSD (368 > max 300).

Используя эту команду, мы можем лучше видеть взаимосвязь между цифрами:

pool :17 18  19  20  21  22  14  23  15  24  16 | SUM
------------------------------------------------< - *total pgs per osd*
osd.0 35 36  35  29  31  27  30  36  32  27  28 | 361
osd.1 29 28  29  35  33  37  34  28  32  37  36 | 375
osd.2 27 33  31  27  33  35  35  34  36  32  36 | 376
osd.3 37 31  33  37  31  29  29  30  28  32  28 | 360
-------------------------------------------------< - *total pgs per pool*
SUM :128 128 128 128 128 128 128 128 128 128 128

Прямая корреляция между количеством имеющихся у вас пулов и количеством групп мест размещения, которые им назначены. У меня есть 11 пулов в фрагменте выше, и каждый из них имеет 128 пг, и это слишком много! Мои разумные значения по умолчанию - 64! Итак, что случилось?

Я неправильно понял, как используются "разумные дефолты". Когда я устанавливаю свое значение по умолчанию на 64, вы можете видеть, что у ceph учитывается моя карта сокрушения, где У меня есть домен с ошибкой между сайтом a и сайтом b. Ceph должен гарантировать, что все, что на сайте a, по крайней мере, доступно на сайте b.

НЕПРАВИЛЬНО

site a
osd.0
osd.1 TOTAL of ~ 64pgs

site b
osd.2 
osd.3 TOTAL of ~ 64pgs

Нам понадобилась общая сумма 64 пг на пул, поэтому наши разумные значения по умолчанию должны были быть установлены на 32 с самого начала!

Если мы используем ceph osd pool create <pool> 32 32, то это означает, что отношения между нашими pgs на пул и pgs за osd с этими "разумными значениями по умолчанию" и нашими рекомендованными max pgs per osd начинают иметь смысл

Итак, вы разбили кластер ^ _ ^

Не беспокойтесь, мы это исправим. Процедура, которую я боюсь, может варьироваться в зависимости от риска и времени в зависимости от того, насколько большой ваш кластер. Но единственный способ чтобы обойти это, нужно добавить больше хранилища, чтобы группы размещения могли перераспределяться по большей площади. ИЛИ мы должны переложить все на вновь созданных пулов.

Я покажу пример перемещения пула default.rgw.buckets.data:

old_pool=default.rgw.buckets.data
new_pool=new.default.rgw.buckets.data

создайте новый пул с правильным подсчетом pg:

ceph osd pool create $new_pool 32

скопируйте содержимое старого пула в новый пул:

rados cppool $old_pool $new_pool

удалить старый пул:

ceph osd pool delete $old_pool $old_pool --yes-i-really-really-mean-it

переименуйте новый пул в 'default.rgw.buckets.data'

ceph osd pool rename $new_pool $old_pool

Теперь может быть безопасная ставка для перезапуска ваших радиошоу.

НАКОНЕЧНО ПРАВИЛЬНО

site a
osd.0
osd.1 TOTAL of ~ 32pgs

site b
osd.2 
osd.3 TOTAL of ~ 32pgs

Как вы можете видеть, количество пулов увеличилось с тех пор, как они добавлены идентификатором пула и являются новыми копиями. И наш общий pgs за osd находится под ~ 256, что дает нам возможность добавлять пользовательские пулы, если это необходимо.

pool :  26 35 27 36 28 29 30 31 32 33 34 | SUM
-----------------------------------------------
osd.0   15 18 16 17 17 15 15 15 16 13 16 | 173
osd.1   17 14 16 15 15 17 17 17 16 19 16 | 179
osd.2   17 14 16 18 12 17 18 14 16 14 13 | 169
osd.3   15 18 16 14 20 15 14 18 16 18 19 | 183
-----------------------------------------------
SUM :   64 64 64 64 64 64 64 64 64 64 64

Теперь вы должны проверить свой кластер ceph на все, что в вашем распоряжении. Лично я написал кучу python over boto, которая довольно быстро проверяет инфраструктуру и возвращает статистику по ковшам и метаданным. Они обеспечили мне, что кластер возвращается к рабочему порядку без каких-либо проблем, которые он понес ранее. Удачи!

Фиксирующий пул default.rgw.buckets.data имеет гораздо больше объектов на pg, чем в среднем (слишком мало pgs?) раз и навсегда

Это довольно буквально означает, что вам нужно увеличить pg и pgp num вашего пула. Так сделай это. Со всем упомянутым выше. Однако, когда вы это сделаете, обратите внимание, что кластер запустит backfilling, и вы можете посмотреть этот процесс%: watch ceph -s в другом окне терминала или экране.

ceph osd pool set default.rgw.buckets.data pg_num 128
ceph osd pool set default.rgw.buckets.data pgp_num 128

Вооруженный знаниями и уверенностью в системе, представленной в вышеуказанном сегменте, мы можем четко понимать взаимосвязь и влияние такого изменения на кластере.

pool :  35 26 27 36 28 29 30 31 32 33 34 | SUM
----------------------------------------------
osd.0   18 64 16 17 17 15 15 15 16 13 16 | 222
osd.1   14 64 16 15 15 17 17 17 16 19 16 | 226
osd.2   14 66 16 18 12 17 18 14 16 14 13 | 218
osd.3   18 62 16 14 20 15 14 18 16 18 19 | 230
-----------------------------------------------
SUM :   64 256 64 64 64 64 64 64 64 64 64

Можете ли вы догадаться, какой идентификатор пула default.rgw.buckets.data? haha ^ _ ^

Ответ 2

В Ceph Nautilus (v14 или новее) вы можете включить "Автонастройку PG". См. Эту документацию и эту запись в блоге для получения дополнительной информации.

Я случайно создал пулы с живыми данными, которые я не смог перенести для восстановления PG. Потребовалось несколько дней, чтобы восстановить, но PG были оптимально настроены с нулевыми проблемами.