LINUX.ORG.RU
ФорумAdmin

Разные по объему диски под OSD в пределах одного хоста, насколько критично использовать в продуктиве?

 , ,


0

2

Добрый день!
Насколько критично в пределах одного хоста иметь разные диски под OSD? Сам массив у нас состоит из 9 нод, на 3-х из них стоят мониторы. Изначально в каждом сервере у нас стояло по 14 дисков объемом в 900Гб и 4 диска SSD объемом в 200Гб под журналы. 4 OSD приходились на 1 SSD. Постепенно у нас начались появляться сообщения о переполнении тех или иных OSD, reweight делать я не стал. Решили накинуть HDD, но были в наличии тогда объемом только 1,8Тб. Поставили их по 4 штуки на 3 сервака, SSD добавлять не стали. Сейчас теперь пытаюсь понять, столкнулись с тем, что при обновлении с Hammer на Jewel, используя флаги noout и norebalance, когда я тушил OSD на одном из серверов, у которых есть диски 1,8Тб у меня начинает повисать работа серверов в OpenStack (релиз Newton). Сами виртуалки выдают окно приглашения и пингуются, но провалится в них все равно нельзя. По мониторингу вижу на таких виртуалках большой процент по ожиданиям io. В кластере Ceph у нас используется распределение сетей, под кластерную сеть у нас собрано в агрегацию round-robin 2 оптических интерфейса по 10G. Под публичную сеть пока 1 гигабитный интерфейс без агрегации (в будущем будем тоже переводить на агрегацию по оптике). Вообще даже не только при этом обновлении, но и ранее когда выбивалась одна из нод Ceph'a, мы сразу это замечали, сервера в OpenStack моментально повисают, пингуются, выдают приглашение для ввода логина с паролем, но дальше уже провалится нельзя, клиент SSH просто висит. На некоторых виртуальных серверах потом можно заметить различные сообщения kernel task blocked for more than 120s для разных утилит. Пока причину такого поведения виртуальных серверов в OpenStack'e при вылете одной из нод в массиве, мы не можем найти. Так же забыл написать, на данный момент у нас 138 OSD, PG 6656, 4 пула и osd pool size = 3 (для любого пула). Основной посыл темы конечно узнать стоит ли использовать разные диски в массиве, но и если кто-нибудь может подсказать в какую сторону рыть по поводу повисания виртуалок, буду очень благодарен.


Для начала ceph.conf в студию

Судя по-моему опыту у ceph нет проблем с разными размерами дисков при условии корректно-выставленных весов, но у меня опыт эксплуатации только на маленьких инсталляциях

Pinkbyte ★★★★★
()

Нет, не критично. Задаются веса и ceph сам раздаёт соответствующее количество PG на каждый OSD.

Hanuken
()

Для ситуаций, описанных выше, есть команда

ceph osd reweight osd.id weight

которой скармливается id osd и коэффициент от 0 до 1, где 1 - полный вес osd, заданный в крашмапе.

Hanuken
()

Мониторинг заполненности osd ведётся ? Мониторится производительность дисков ? Мб проблемы при вылете ноды связаны с одним из этих факторов.

Deleted
()

Мой маленький кластерок в разы меньше, но вроде бы это основное отличие ceph от glusterfs. Crush map позволяет смешивать произвольные дисковые конфигурации, а gluster — предпочитает, чтобы все ноды и диски были эквивалентными.

ugoday ★★★★★
()
Ответ на: комментарий от Pinkbyte
[global]
fsid = 90932d9e-8db9-46bc-8d39-3be0d384b659
mon_initial_members = ceph1, ceph2, ceph3
mon_host = 172.28.3.1,172.28.3.2,172.28.3.3
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
filestore_xattr_use_omap = true
osd_pool_default_size = 3
public_network = 172.28.3.0/24
cluster_network = 172.28.46.0/24

Весь конфиг.

amkgi
() автор топика
Ответ на: комментарий от amkgi

Неплохо вести графики, чтоб можно было понимать что и как происходило в определенные моменты времени.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.