@SinTeZoiD ты мануал-то дописал? Публика жаждет

кстати, кто-нибудь пробовал использовать на хостах с osd всякие штуки типа zram?

Видел, на последней саммите по OpenStack доклад о оптимизации CEPH.. Индус там рекомендует использовать vm.swappiness = 0.

Уважаемые пользователи. В связи с тем, что тематика канала перерастает в ceph only, то канал переименовывается в @ceph_ru. Обсуждение openstack переноситься в @openstack_russia для обсуждения облачных технологий создан канал @cloud_ru. Для беспробудного флуда и холиваров канал @cloud_flood.

Может потек osd? Бывает.

с такой реализацией ему сколько не скорми - всё мало будет

Добрый день. Кто-нибудь сталкивался с ситуацией, когда часть OSD, при наличии большого объёма свободной памяти уходит в swap ?

Попробуй убавить размер журнала, если больше 2Гб

а что ты хочешь видеть в мануале?

ты обещал мануал о том, как правильно ставить ceph, чтобы не пришлось его потом сразу же переделывать :)

Достаточно один раз поставить не используя ceph-deploy. Понимание приходит быстро.

Зачем? В доках расписан же алгоритм действий ceph-deploy

Когда делаешь руками, понимаешь как это работает и связано между собой. Как надо помечать партиции, как отформатировать журнал отдельно, структуру каталогов и т.д.

А зачем знать о том, как форматировать журнал отдельно?

Вылетает у тебя диск с журналом. Меняешь и форматируешь без пересоздания osd. Бывает из-за ошибки или невнимательности повесили два osd на один журнал. Разводишь и раздельно форматируешь журналы.

Ну вообще про это отдельно в доках написано. Не, я не спорю, может кто-то лучше запоминает руками команды прогоняя... Мне хватило доков и чтения вывода ceph-deploy)

Журнал так просто не изменить, там так же свои тонкости

Размер журнала 25 гигов партиция, но не уверен, что он заполняется даже на половину.

Кстати, интересно сколько у вас журналы размером ? Я вот думаю может увеличить размер , сейчас у меня по 25gb

Есть формула для расчёта журнала

И видимо в ней будет параметр -- время в течение которого должна быть возможна запись данных на пиковых скоростях. Другими словами чем больше нужно чтобы осд мог проглотить пиковые иопсы и или мегабайты в секунду, тем больше журнал. Разве нет ?

Блин, когда "погугли" будет считаться нецензурным?

Я гуглить буду до морковкина заговения

Я гуглить буду до морковкина заговения

Коллеги, привет. Сейчас будет длиннопост. Нужна помощь. Если не по адресу, подскажите ресурс, куда лучше обратиться? Желательно на Русском, т.к. на Английсом так подробно расписать не смогу. В ЦЕФе и даже в Линуксе новичок. Начинал с десяток лет назад вообще с FreeBSD, но успел многое позабыть. Появилась задача запустить ЦЕФ. Пришлось вспоминать и разбираться. Получилось. Имеется: - 14 узлов хранения. В каждом 36x HDD 6Tb для хранения данных. 2x SSD 80Gb под систему. 2x NVME SSD 800Gb под журналы. Памяти в каждом узле 128Gb. 4 сетевых интерфейса 10G. CPU 2x E5-2630v3. В сумме на кластер получается 504 OSD - 3 узла монитора. Под систему 2x SSD 80Gb. Памяти 64Gb. Сеть 2x 10G Взял релиз Jewel. CentOS 7. Документация: http://docs.ceph.com/ и http://onreader.mdl.ru/CephCookbook/content/index.html Всё установилось и заработало. Единственный пул. Емкость кластера 1.5Пб при коэффициенте репликации 2. Размер журнала для каждого OSD примерно 40Gb (просто тупо разделил доступное пространство на NVME SSD поровну между всеми OSD). Разделены между собой public и cluster сети. osd pool default pg num = 32768 (считал pg num по статье на docs.ceph.com, но в этом вопросе до сих пор плаваю). Но в итоге при любой необходимости ребалансировки кластера, он помирает. В первый раз необходимость ребалансировки возникла после изменения CRUSH MAP - распределил узлы хранения по серверным шкафам. Во второй раз понадобилось перезагрузить один из узлов хранения с целью понять, какой из HDD вышел из строя (физически). В итоге тоже пошла ребалансировка. В обоих случаях результат ребалансировки таков: падает примерно половина всех OSD служб. Остаются в работе от 200 до 300 OSD, равномерно по всем узлам хранения. Кластер в статусе HEALTH_ERR. При попытке вручную запускать OSD, они либо не запускаются, либо запускаются, но при этом падают соседние. Больше 300 OSD запустить не удалось - в процессе recovery они снова падают. Это всё при том, что кластер практически пустой - успели залить в него примерно 20Gb тестовых данных. В продуктив ещё не выпускали. После первого случая вернул кластер к работе удалив единственный существующий пул с данными. После этого все OSD поднялись с пол пинка. Во второй раз удалять данные не стал. Т.к. надо разобраться, что не так, и как это побороть. В данном канале нашел, что причина может быть в том, что кончается память - OOM. Помогите советом, что надо переконфигурировать в кластере, чтоб такого не возникало? Очень хочется уже перейти к тестированию производительности, но не могу. Всем заранее спасибо.

Значит возможно цеф не для тебя)

Значит возможно цеф не для тебя)

Ой всё

Ну если человек не может ввести "ceph journal size", то кто ему доктор

Коллеги, привет. Сейчас будет длиннопост. Нужна помощь. Если не по адресу, подскажите ресурс, куда лучше обратиться? Желательно на Русском, т.к. на Английсом так подробно расписать не смогу. В ЦЕФе и даже в Линуксе новичок. Начинал с десяток лет назад вообще с FreeBSD, но успел многое позабыть. Появилась задача запустить ЦЕФ. Пришлось вспоминать и разбираться. Получилось. Имеется: - 14 узлов хранения. В каждом 36x HDD 6Tb для хранения данных. 2x SSD 80Gb под систему. 2x NVME SSD 800Gb под журналы. Памяти в каждом узле 128Gb. 4 сетевых интерфейса 10G. CPU 2x E5-2630v3. В сумме на кластер получается 504 OSD - 3 узла монитора. Под систему 2x SSD 80Gb. Памяти 64Gb. Сеть 2x 10G Взял релиз Jewel. CentOS 7. Документация: http://docs.ceph.com/ и http://onreader.mdl.ru/CephCookbook/content/index.html Всё установилось и заработало. Единственный пул. Емкость кластера 1.5Пб при коэффициенте репликации 2. Размер журнала для каждого OSD примерно 40Gb (просто тупо разделил доступное пространство на NVME SSD поровну между всеми OSD). Разделены между собой public и cluster сети. osd pool default pg num = 32768 (считал pg num по статье на docs.ceph.com, но в этом вопросе до сих пор плаваю). Но в итоге при любой необходимости ребалансировки кластера, он помирает. В первый раз необходимость ребалансировки возникла после изменения CRUSH MAP - распределил узлы хранения по серверным шкафам. Во второй раз понадобилось перезагрузить один из узлов хранения с целью понять, какой из HDD вышел из строя (физически). В итоге тоже пошла ребалансировка. В обоих случаях результат ребалансировки таков: падает примерно половина всех OSD служб. Остаются в работе от 200 до 300 OSD, равномерно по всем узлам хранения. Кластер в статусе HEALTH_ERR. При попытке вручную запускать OSD, они либо не запускаются, либо запускаются, но при этом падают соседние. Больше 300 OSD запустить не удалось - в процессе recovery они снова падают. Это всё при том, что кластер практически пустой - успели залить в него примерно 20Gb тестовых данных. В продуктив ещё не выпускали. После первого случая вернул кластер к работе удалив единственный существующий пул с данными. После этого все OSD поднялись с пол пинка. Во второй раз удалять данные не стал. Т.к. надо разобраться, что не так, и как это побороть. В данном канале нашел, что причина может быть в том, что кончается память - OOM. Помогите советом, что надо переконфигурировать в кластере, чтоб такого не возникало? Очень хочется уже перейти к тестированию производительности, но не могу. Всем заранее спасибо.