Коллеги, привет. Сейчас будет длиннопост. Нужна помощь. Если не по адресу, подскажите ресурс, куда лучше обратиться? Желательно на Русском, т.к. на Английсом так подробно расписать не смогу. В ЦЕФе и даже в Линуксе новичок. Начинал с десяток лет назад вообще с 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. Помогите советом, что надо переконфигурировать в кластере, чтоб такого не возникало? Очень хочется уже перейти к тестированию производительности, но не могу. Всем заранее спасибо.

Или вы предлагаете без полного ориентирования в теме оценивать релевантность

Или вы предлагаете без полного ориентирования в теме оценивать релевантность

Естественно блин он релевантна!

С чего бы это? Вы еще и надеетесь, что документация это решение всех проблем?

Видимо канал можно сразу вот так взять и закрыть, ведь все есть в доке

О, вы все таки добрались до этого чата?) В логах OSD что?

Михаил, привет. Предлагаю общаться на "ты". Коллеги как никак). Да добрался. Спасибо. Пока служба OSD лежит, в ее лог естественно ничего не пишется. Когда запущена, пишется, но детально еще не изучал, визуально вроде не сильно отличается от лога нормально работающего кластера. Какой еще лог посмотреть, чтоб понять, что творится с узлом в целом?

Михаил, привет. Предлагаю общаться на "ты". Коллеги как никак). Да добрался. Спасибо. Пока служба OSD лежит, в ее лог естественно ничего не пишется. Когда запущена, пишется, но детально еще не изучал, визуально вроде не сильно отличается от лога нормально работающего кластера. Какой еще лог посмотреть, чтоб понять, что творится с узлом в целом?

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

у меня есть ощущение, что когда потом тот же человек придет с "ребят, у меня кластер упал, я его настроил с помощью ГСЧ и удачи", ответом здесь ему будет то же самое

А может и не будет. На моей памяти тут людям помогали

Если по мануалу - то на ноде хранения должно быть > 216гб памяти 🤔

Коллеги, привет. Сейчас будет длиннопост. Нужна помощь. Если не по адресу, подскажите ресурс, куда лучше обратиться? Желательно на Русском, т.к. на Английсом так подробно расписать не смогу. В ЦЕФе и даже в Линуксе новичок. Начинал с десяток лет назад вообще с 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. Помогите советом, что надо переконфигурировать в кластере, чтоб такого не возникало? Очень хочется уже перейти к тестированию производительности, но не могу. Всем заранее спасибо.

Я буду настаивать на своем и в твоем случае, больше повторять не буду, сделай эурнал 2Гб и скорее всего поможет

Так же сеть надо оптимизировать при таком большом количестве osd

С сетью отдельный вопрос. Являясь по сути Windows админом пришлось разбираться как в Linux, так и в сетях. Сеть настроил по наитию. Для каждой сети Ceph (custer и public - в разных вланах) объединил в LAG по два интерфейса, получив в сумме по 20Gbit на сеть. Jumbo frames в наличии. Со стороны всё работает нормально. Естественно, нужен сетевик, чтобы провести ревизию. Скоро будет в штате, поручим ему это. Как проверить качество работы журналов?

Blog.disksurvey.org - про taking too long. И тп

Коллеги, привет. Сейчас будет длиннопост. Нужна помощь. Если не по адресу, подскажите ресурс, куда лучше обратиться? Желательно на Русском, т.к. на Английсом так подробно расписать не смогу. В ЦЕФе и даже в Линуксе новичок. Начинал с десяток лет назад вообще с 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. Помогите советом, что надо переконфигурировать в кластере, чтоб такого не возникало? Очень хочется уже перейти к тестированию производительности, но не могу. Всем заранее спасибо.

коэффициент репликации 2 плохая мысль. Есть неиллюзорная вероятность потерять данные.

Планируем в продуктиве сделать 3. В тесте пока так.

Коллеги, привет. Сейчас будет длиннопост. Нужна помощь. Если не по адресу, подскажите ресурс, куда лучше обратиться? Желательно на Русском, т.к. на Английсом так подробно расписать не смогу. В ЦЕФе и даже в Линуксе новичок. Начинал с десяток лет назад вообще с 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 задумывался как медленное хранилище "холодных" данных. Самое интересное в том, что это хранилище должно подлючаться к VMWare 😱. Начинал это дело проектировать мой коллега, который до конца не допроектировав перешел работать в другое место в тот самый момент, когда оборудование уже оплатили и почти привезли. Всё оборудование "досталось" мне. Из коллеги удалось выудить информацию, что прослойкой между Ceph и VMWare планировался NFS. Т.е. сначала на Ceph-клиентах маппится блочное устройство Ceph, а затем отдается в VMWare как NFS шара (в качестве датастора или напрямую в виртуальную машину). Реализацию этого решения у коллеги выудить не удалось, по этому пришлось самому разбираться. В итоге родился "An active/passive NFS Server in a Red Hat High Availability Cluster" (на отдельных машинах от OSD и MON). Не знаю на сколько это оптимально, но работает. Если кому-то интересно, могу поделиться опытом. В этом же канале прочитал, что есть решение iSCSI, ещё к тому же и active/active. Планирую разбираться в этом вопросе, как только разберусь с текущей проблемой ребалансировки кластера.

Только зачем vmware не оч понял, на qemu-kvm имхо проще подключить.

Задача специфическая. Ceph задумывался как медленное хранилище "холодных" данных. Самое интересное в том, что это хранилище должно подлючаться к VMWare 😱. Начинал это дело проектировать мой коллега, который до конца не допроектировав перешел работать в другое место в тот самый момент, когда оборудование уже оплатили и почти привезли. Всё оборудование "досталось" мне. Из коллеги удалось выудить информацию, что прослойкой между Ceph и VMWare планировался NFS. Т.е. сначала на Ceph-клиентах маппится блочное устройство Ceph, а затем отдается в VMWare как NFS шара (в качестве датастора или напрямую в виртуальную машину). Реализацию этого решения у коллеги выудить не удалось, по этому пришлось самому разбираться. В итоге родился "An active/passive NFS Server in a Red Hat High Availability Cluster" (на отдельных машинах от OSD и MON). Не знаю на сколько это оптимально, но работает. Если кому-то интересно, могу поделиться опытом. В этом же канале прочитал, что есть решение iSCSI, ещё к тому же и active/active. Планирую разбираться в этом вопросе, как только разберусь с текущей проблемой ребалансировки кластера.

Задача специфическая. Ceph задумывался как медленное хранилище "холодных" данных. Самое интересное в том, что это хранилище должно подлючаться к VMWare 😱. Начинал это дело проектировать мой коллега, который до конца не допроектировав перешел работать в другое место в тот самый момент, когда оборудование уже оплатили и почти привезли. Всё оборудование "досталось" мне. Из коллеги удалось выудить информацию, что прослойкой между Ceph и VMWare планировался NFS. Т.е. сначала на Ceph-клиентах маппится блочное устройство Ceph, а затем отдается в VMWare как NFS шара (в качестве датастора или напрямую в виртуальную машину). Реализацию этого решения у коллеги выудить не удалось, по этому пришлось самому разбираться. В итоге родился "An active/passive NFS Server in a Red Hat High Availability Cluster" (на отдельных машинах от OSD и MON). Не знаю на сколько это оптимально, но работает. Если кому-то интересно, могу поделиться опытом. В этом же канале прочитал, что есть решение iSCSI, ещё к тому же и active/active. Планирую разбираться в этом вопросе, как только разберусь с текущей проблемой ребалансировки кластера.

по поводу iscsi хочу предупредить что с цефом через LIO ESXi не очень дружит, после лага со стороны хранилища ESXi впадал в коматозное состояние

Прикольно, давно тестили?

совсем недавно, у меня конечно довольно лагающий цеф кластер, но впадающий от этого в коматозное состояние гипервизор как-то не очень выглядит ESXi 5.5

Денег стоит

Ну если вмвару купили, то чо нет. А если не купили, то тоже а чо нет?

Импортозамещение и гос заказчик